Shane's full question: Good day. This is Shane Hastie with InfoQ. We're here at Agile 2013. We've got Ian Culling, the CTO of VersionOne, and VersionOne are one of the title sponsors of the conference this year and have been for a number of years. Ian, first, thank you very much for taking the time to come and talk to us at InfoQ. Would you mind briefly introducing yourself to our audience?
Ian: Sure, absolutely. As Shane said, my name is Ian Culling. I'm CTO of VersionOne. I've been there for about seven years. I'm responsible for product development, internal IT and a hosted operations.
2. Now VersionOne is an Agile company from the top down, aren't you?
Ian: Pretty much, yeah. We were, I mean, founded to build the product that we offer to the market today so from the get-go, yeah.
Shane: Why?
Ian: Well, we're passionate about Agile methods having had - personally I had some history in some serious waterfall, document-driven, CYA kind of projects in the past, full on death marches. When I stumbled across Kent Beck's white book back in like 2000, lights came on. I mean, it was something that - obviously, the pragmatism, the low ceremony, the discipline really, really struck a chord with me and I immediately started transitioning the team that I was working with then to XP and life became much saner. It's a much healthier way to run projects, and so it's a logical thing for us to do to build a product to help support people make that transition.
3. And you're using all of these techniques deep inside your development process?
Ian: We do. Our team and our methods are evolving all the time so we try to keep - just continuously improve.
Ian: Well, from a team perspective, continuous improvement I think for us really started to kick in with the addition of some of the right people. I think that's important. So you have to have some people that are more open to change to really drive like as catalyst for improvement.
When I joined seven years ago, it was a tiny team, very focused on getting an initial product out to market. Not much time to stand up and look around at what's going on in the outside world and very settled into practices that they'd been using for two to three years. We started growing the team, brought in some people that were a little more adventurous, a little more open to change. I think through the combination of people and healthy frequent retrospectives we've become a much more experimental team and willing to try new things for a period of time. I think that was a key for some of the folks that are less, or maybe a little more change averse. If you can get someone to commit to trying a new thing for a couple of weeks and if it's not working, then you stop doing it. If it's working, then you continue with it.
So I think the combination of those two things were what really turned what was a team that maybe wasn't so interested in trying new things into one that's pretty eager to try new things.
5. So you're, what, regularly doing a lot of smaller experiments?
Ian: We are. We don't really run in iterations anymore, but we do have a cadence of two weeks so we will do a retrospective every two weeks. We'll do a companywide demo every two weeks, features that we've delivered and that kind of thing. So retrospectives tend to be about how well are we doing as a team?
In the past, we've tried having a retrospective board where things that people want to try or things that are not working get put up on the board during the course of, say, a couple of weeks and then you've got them queued up for having kind of rich conversations about ways to get better.
6. So the retrospective process itself also evolving?
Ian: Oh, yeah, all the time. Standup has evolved continuously over the last -- we've tried all kinds of different ways of doing standup as an example just to make it valuable and efficient and interesting for people.
7. That's inside the team. What about at the executive and management layers?
Ian: So we'll do quarterly planning sessions that are focused on obviously where we're taking the company but also how well things are working both within our groups and across the entire company. So it's a little less frequent but certainly has the same sort of culture of improvement, right? So people will come and visit and then we'll with partners or customers. They'll be very complimentary about what we do and how we work, and we sort of think we have tons of room for improvement all the time and that's a cultural thing. So have a sense of humility and know that there's always ways to get better.
8. That work culture, why does it matter? What's the secret sauce?
Ian: It has a lot to do with people that you hire obviously. I mean it is people. Culture is a reflection of your people and the way they work together. I think we've done a really good job of growing the company judiciously and bringing in the right people and taking care of mistakes when we've made them which have been very few and it really has as much to do with protecting the culture that we have.
The foundations of culture are really, trust, transparency, making sure people have sort of faith in the information that they're being provided. They know where they're going. Honesty and respect are pretty critical. Talking about sort of company culture and team culture, I mean it starts with individuals and I think one of the things that we look for in people that we bring in to really any part of the company but I'm obviously most focused on recruiting for our team, they really are craftsman, like people that take their craft seriously, look at software development as - they're passionate about it, want to work with really smart people who are also passionate and learn from each other. I think that is obviously - there's a really positive feedback from a cultural perspective. Those are the kind of people that we all want to be around and learn from.
And then I think from a leadership perspective, from Robert on down I mean he's extremely honest and open and shares pretty much everything there is to share about the company and has never misled people in terms of like when asked a question he'll give an answer or he'll tell you he can't tell you like if it's something that's whatever.
I think one of the other big things from my perspective is we don't really have much static between organizations and teams, the boundaries are really, really loose and people are -- and that's not been the case for me in places I've been at previously where sales is unto development about something or marketing or this stuff or the other kind of stuff. It's very healthy from that perspective and I think that's a reflection of Robert and the rest of the leadership team, having trust and faith in each other.
9. That cultural collaboration that you mentioned earlier starts right at the top?
Ian: Oh, yeah. Yeah, absolutely. I think it's happening more often now where we've got some cross-functional teams focused on improving trials, for instance. So marketing, sales, development, product management all working together consistently with a common set of goals and we started that probably two to three months ago. That's really starting to be successful, and it's a lot of fun working with people from other disciplines.
Ian: We have a very open workspace and I think we have a very open feel within the team from a communication and collaboration perspective. So we pair most of the time, developers pair a lot of the time. Some pair very little but we don't dictate. It's just the way that we for hire people that are more social like social coders versus the hardcore introvert with the headphones. So I think that matters. That's a big deal in terms of bringing in the right people who like to work with other people. A big part of our recruiting is we'll have them come in and pair up with someone and go through an exercise and work on real things to see how they feel about that as a way of working and to see how they kind of adjust or fit into working that way and I think that's really important.
I also think from a leadership perspective, you kind of have to let things go. You can't jump in to conversations all the time and try to steer things because that really kills that vibe. And so there are times when there are cat videos flying around through all over the place and it's a bit chaotic and you've got to let that stuff happen. If you jump in and try to control the situation, people will stop kind of working well together. It kills the vibe for sure.
Shane: As a leader in a team like that, you got to be very, very conscious and aware of what is happening.
Ian: You do. There are times when it's really, really hard. It’s like, "Stop screwing around. We have stuff to do here," or I know this is a mistake just having had whatever, years of experience and a sense for the right direction and stuff and those kinds of things. But as soon as you step in and start doing that kind of stuff, people shut down, I found.
IanHave a lot of trust and faith in the people that you hire onto your team and give them a ton of rope. Make sure they know where they're going like where you're headed, where you're taking the product and let them do their job. I think that's really important. Make sure they have all the tools they need. Make sure they know that you're interested in their personal and professional growth and have opportunities both within the team and the way they work to grow but also obviously have opportunities to do things like come to this conference or other conferences or user groups or speak or those kinds of things too. So we strongly encourage that kind of stuff too.
Shane: Ian, thank you very much for taking the time to talk to us today. We really appreciate it. Enjoy the rest of the conference.
Ian: Thanks. I appreciate it.
Andy: Sure, Shane. So Product Evangelist, I look at it as supporting the company in two ways. One is with our customers, making sure they understand the vision for where we're headed. That's something that's important. If you're in the buying stage or you're looking at how does VersionOne help me but also something, just current customers, they care a lot about where our product is heading because they care about how they're managing their software development process. So having those discussions with them to talk to them about where we're heading and then get their input into where they see things happening and how we could further help them where they see the value in what we can provide.
I also get involved with more of a marketing side, just helping get our message out there, get involved in webinars and trying to make sure that people know the good things we're doing.
Shane: We'll come back to those good things you're doing and talk about the future of the product, but I'd like to tackle a couple of things. We were chatting earlier on, and you said one of the things that you're having a lot of conversations with people about out there as part of your role is helping them to bring Agile in where you've got PMOs and integrating in the Agile process into the overall structure of project management organizations. How is that working and what's happening there? Because this is often a challenge for organizations.
Andy: Yeah, we've seen it to be a big challenge. And what's happened is a lot of our customers have got an Agile limitation, and they're being pretty successful on the team level. They've done a lot of training whether it's Scrum or some other flavor of Agile. So they have these teams being very successful about delivering stories. They're starting to look at how to integrate that into their businesses as a whole and they're hitting these roadblocks. When the development organization talks to PMO, they come from such different mindsets that they're having a hard time overcoming some of those communication barriers.
So where the PMO is saying, "Oh, I need to figure out what to do in the next release. I have to understand your capacity," a lot of times the development organization is saying, "Well, come back to not Agile." So they kind of have this butting of heads that occurs. And for VersionOne's perspective we tend to try to be as pragmatic as we can about things. When we look at that conversation, it becomes more of "Okay, well, the PMO does need to plan and what should that planning look like? How do you do that planning?" More of a rough-cut capacity planning in an Agile fashion to get the business the answer it needs.
So just working through that conversation, it really came clear to us how important it is because we start to see from a tooling side a lot of our customers wanted to integrate VersionOne with their PPM solution. So when they start to look at how does that work, what is the workflow, they really have to come to grips with those conversations and then start having them internally. It's kind of the same conversation every time and so we have started to try to help people work through that so that they can get past their differences and focus on where the common ground is.
13. What are some of the things that help in that regard? What advice would you give?
Andy: We've seen three patterns. One is that you really have to recognize that you still need capacity planning if you're doing a large-scale software development, and it's just changing from managing people to managing teams. I think once you can come to that common ground with the PMO and help them understand that if you have stable teams, you still have potentially some cross-team dependencies you have to resolve then you can get to work of figuring out how you can resolve those. So that's one topic is to kind of Agile capacity planning.
Another topic that we've seen be really important is around being able to track time. So a lot of times, even at development organizations feel like tracking time is essential and we're starting to see a lot of that. More Agile organizations really look at them and say, "Well, it's not helping us deliver better software." There may be a little bit of value in helping us get better with our estimates but a lot of mature teams would say, "I'd rather be spending my time focusing on -- thinking about the customer than thinking about where my time went as a developer." I think there's merit in that.
So finding a way that you can provide some allocation of where your time went without having to track detailed hours for each task is possible and once you start to have a realization that, "Okay. We can do that." And so that's another key area we've seen.
The third area where we've had a lot of discussions is around just progress tracking. This whole concept of tracking percent complete is something that at this point we need to move away from as a software organization, focus more on delivering our features. I think that's largely in the Agile Manifesto but it's helping the PMO realize that and really supporting their need to communicate back to the business, doing it through feature completion, something of value that the business understands as opposed to a percent complete which they really don't.
And so, those are the topics that I feel like are really getting in the way a lot of times with the PMOs -- how do you track progress, how do you allocate time and then also how do we do capacity planning. I think there's starting to be some good answers out there. From a tooling perspective, we're looking to try to integrate those into the product to make it easier for people to do what they need to do.
Andy: I think that's a good topic. That's another space with "Hey, what should we be measuring?" We're starting to see some more maturity come out. A lot of traditional PMOs, one of their tasks is to measure the efficiency of development. So they're looking at how can development get better at delivering and faster and all those things. What the business cares about is how can we deliver better to the actual users. I think that's the space where we're starting to see much more momentum around measurements. If the development organization -- and this might not fall with the PMO but as a whole if we can start looking at what are the actual end users doing, then we're at a much better position.
For example, one of our larger customers, they deliver software to hospitals. For them, before they agree to work on a feature, they have to get a hospital to commit to taking on that new feature quickly. They're looking to use that almost beta customer as a way to fund the work. If they can't fund the beta customer, then it can't be that valuable.
On a kind of a more enterprise scale, that's one strategy. And then on the smaller scale, you've got a lot of the user analytics tools out there. They're starting to pop up where even development can start getting some real insights into how our users take advantage of a product, what features are being used, what shelfware that we don't want to continue to invest in or what do we put out there that hasn't quite reached the tipping point. We need continue investing to get to where we think we are. And so there's a lot of better tooling out there so we can get away from just trying to get the project done and focus more on making sure we're adding value to our end users.
15. So what are some of the - well, not so much what are the tools but how does an organization do this?
Andy: I think largely it has to come from realizing that in order to start responding to feedback, one, you have to have a mechanism for getting it and then you have to be structured to respond. And so I think one of the best things an organization can do is shorten their release cadence so that they're starting to say, "Okay, every quarter, every ten weeks, we are actually going to go back and think about what we're doing next."
What we've seen is when a customer starts to -- in the business starts to realize that IT can deliver on a short cadence and they really start doing it. The way they behave changes so they're not thinking, "I need to get all my projects in the queue." They're thinking, "Hey, what do we need to get done in the next quarter?" A lot of large organizations, that's not the way the business is thinking. There's not really much incentive to react to the new information you're getting because you know it will take a year to get it into the pipeline.
So really figuring out that right mix for inside an organization because it's a place where there should be a lot of management attention put, and that's an area where I think development has ability to start really leading somewhat because they know that if they start to put the right infrastructure in place, they can deliver on those timeframes. But it does take some buy-in and commitment from development leadership to make that happen.
16. Buy-in and commitment, where do you get that? What do leaders need to do?
Andy: Well, I think it starts with investing time and recognizing that you can't keep going the exact same way you're doing, and so you're going to have to make some strategic investment in something like DevOps so you can get product out faster. You're not just focused on trying to get a project done, but you're thinking about how can I get the next project done in a better fashion?
And so, from that standpoint, getting the development leadership to really understand the principles of product development flow I think is an area that if you have good leadership, they may know those principles just from their experience within the development industry. But I think what I've seen is there's a fair amount of lack of understanding about how do you really deliver software in a large-scale company well and to communicate those principles across the company. And I think the Agile community is starting to provide some good guidance there.
So that's an area where in the last couple of years VersionOne has been focusing its energy, and I think a lot of the thought leadership has to make it easier for those organizations to transform because you really have to get everyone on board and getting them on board means they have to internalize where you're trying to go. It's pretty complex stuff so it's not an easy task for anyone to make it happen on their own. You really have to get a lot of buy-in across the board.
Shane: We can't just drop in a product.
Andy: Exactly.
Andy: Yes. In this latest release, there's been a couple investment teams for us that we've been focused on over the last few years. One of them is supporting the concept of enterprise Agile and Agile portfolio management better. We started to see a lot of our customer's grow up in terms of how they're thinking about it.
One of the things I've mentioned earlier this focus on teams. So Agile teams everyone gets but what you see, what you scale to a hundred people delivering something is you actually need product teams and release teams and there's other teams forming. So we're coming out at our next release just announced today with PlanningRooms. PlanningRooms are all about that common place where your planning team can come to say, "Well, how are we progressing on this release? Based on what we know today, how do we want to think about moving forward having conversations around the key features that we're working on."
So giving them that place where they can come in and almost have a portal to stay on the same page so they're not at a meeting discussing what's going to happen next they're able to continue the collaboration. So PlanningRooms help with that; structures that large organizations need.
And then another element we're coming out to release is around collaboration and it's Conversations+. So Conversations is our collaboration platform. What's nice about it is that it allows you to capture what you're talking about onto your different assets in VersionOne. So you have a great context around any discussions you're having unlike something like email where a lot of times it gets lost, and you can't link it back to your assets. It's very easy to have that connected conversation with VersionOne.
With Conversations+, what we're doing is removing the barriers to saying, "Well, this person is in VersionOne, but I really like to bring these other people who aren't into my collaboration." And so now, you can invite anyone with an email and bring them into a conversation very easily. So if you're someone doing discovery on a new feature and you've got a business stakeholder who it doesn't really log into VersionOne, has never needed a licensed before, you can bring them in to this existing communication stream you're having and allow them to be a part of it and add their perspective.
We're excited about that as a way to continue the collaboration that a lot of times get stuck inside of dev and help break down some of those barriers between development and the users of the software they're creating.
So those are, I would say, the two headliners. And then we're also -- the third thing we have in the release is we're introducing some SAFe reports to support some of the SAFe metrics so the Scaled Agile Framework is something we're seeing more of from our customer base and for prospects looking at how to scale Agile. And so providing some reports that have an outline within SAFe that covers some of the metrics that are helpful across different levels within Agile software development.
18. So aligning very tightly with the SAFe Structure?
Andy: I think the SAFe structure really aligned itself to the principles of product development flow. So Donald Reinertsen wrote I think a wonderful work for anyone who's developing products, not just software products. I think SAFe is a good implementation of a lot of those principles. And what VersionOne looks for when it delivers product is to say, "Hey, let's deliver product that's working." And we feel like following a lot of those principles is a good way for us to improve the product.
A lot of the principles that SAFe has really come out with have been in VersionOne for years. And so I think they've also come out with some aspects and thought through some elements that we're now looking at and saying, "Hey, this will be valuable to our customers and including those in the product as well."
Shane: Andy, thank you very much for taking the time to talk to us at InfoQ today and hope you enjoy the rest of the conference.
Andy: Yeah, my pleasure. Thank you, Shane.
Lee: Sure, yeah. Again, name Lee Cunnigham and I've been with VersionOne for a little over four years. I came to this Agile thing the way a lot of folks did, kind of fell into it sideways as my work progressed as a Development Manager. First, starting as a Software Engineer and then a Manager in software engineering and then getting into projects from program management and realizing that the things we were doing weren't quite working right.
So doing things that came intuitively like moving, testing forward in the process, letting the team members make decisions about things they should be making decisions about so on and so forth, just made sense when they were working. And then I realized one day there was a movement around this stuff. So I was actually part of something. That's how I ended up really gravitating towards Agile. It was a very natural progression for me.
And then I eventually joined VersionOne. I've spent the last few years working as a coach primarily in the enterprise space. And the Enterprise Agile Coach title is actually just a growth of that. It's allowing me to devote more of my time to working with our customers and prospects who are looking to take what has been working well for them at the team level and say, "Well, now we need to scale this out," but we're not really sure how to do it. We've heard of frameworks like SAFe and Disciplined Agile Development and maybe some homegrown things, but we really need some help figuring out the ins and outs. "Can you come and share your experience with us, kind of roll up your sleeves and help us work this out?" That's the bulk of what I do.
Lee: One of things that we see a lot especially with the advent, say, of the Scaled Agile Framework is that at a glance, it looks like multitier big planning upfront type of approach. It really appeals to larger organizations because it looks like there is a structure and architecture around Agile and it is. But what happens upon closer examination is that they realized it's really just a scaling up of what needs to be already established solidly at the team level.
So a common comment that I give to folks looking into this is you can't scale what you don't already have. So I think there's a realization that it's not going to be easy and none of this stuff has ever been portrayed as being easy, but it can appear to be easier than it seems when you look at it a picture or you're just going to look at it in glance.
So I think what we're seeing is that there is a real need for, especially that middle layer between the team level, say, at the bottom and at the portfolio layer at the top, in the middle, that program layer where everything comes together and meshes together is where the real tangle is. So that's the commonality. That's the problem folks are trying to solve.
The other one that they're seeing is that Agile is still seen largely as something that the team does, something that the engineering organization does. The business side is "being brought along" slowly, certainly a lot more adoption now than there was, say, three to five years ago but that is still an inherent problem is getting the organization top to bottom to realize that Agile is not just something that the team applies to engineering practices, but it really is an organizational, transformational type of thing.
21. And what are the challenges to making those organizational transformations?
Lee: I think one of the biggest challenges is just getting the senior levels in the organization to stop long enough to listen to the message. Often they are preoccupied, that part of the organization has its attention diverted elsewhere because the engineering organization is just an enabler of the business.
So you especially see that with internal software when you're talking about an interim department that's just supporting the business of the business and where the software itself is not the business. So where you have commercial software, it's a much easier case to make because it's much more visible. But in cases where your organization is just producing software to sustain its business, the software efforts are looked at just as a cost center. It might as well just be a paperclip or a Post-it note. It's just another resource in there.
So the concept of return on investment is kind of a foreign thing and some of the concepts we're trying to portray such as lean flow and cutting out the waste just don't - there just doesn't to be the time to listen to that. And that's really important to have an understanding of that from the business side so that the other parts of the organization could work well.
Lee: Yeah. That's a good question. Something that I stumbled across a few years ago was the concept of throughput economics, throughput accounting. The light bulb just came on for me. That is something that I always try to stress even when I'm doing team level just boot camp training for team members. I make sure they understand it. On the off chance, they're going to be in the elevator for 30 seconds with somebody who wants to know, "Hey, what are you guys doing down there?"
I think that's important for everybody in the organization but especially those who are controlling the first drink, so to speak, to understand that this is not something that suggests an add-on methodology, that you can actually become better at this, you can become leaner at this, you can actually get a higher return on your investment and develop and deploy things that are actually valuable and save money in the process.
23. What is the core of that flow?
Lee: Yeah. So the core of that really is that until you've delivered something that works and is valuable, all you've done is spend money. That's really the bottom line. If you think about going from left to right mentally, on the left side, you've got ideas that feed into this process where you're coding and testing and maybe some churning back and forth there and eventually on the right side of the diagram, you're deploying something, everything up to that deploy is a negative sign.
So the investment in requirements, the investment in the coding, the investment in the testing, the investment -- all the DevOps and everything has to happen, it only pays off when there's an opportunity to deliver something whether that's externally as commercial software or even just internally as numbers change sides of the ledger inside of an organization.
So having people understand that that is the case and that earn value is that you're incrementally earning value as you get things partially done is really a - it's a paper chase. So having folks understand that you've got to deliver something that works, deliver something that's valuable and deliver it as frequently as possible to increase the R side of the ROI is really where it's at.
And that's the hard part. The ROI question is always one that I always kind of laugh at because I ask people, how are you measuring the return? That's a nebulous thing, very hard to pin down. We can't know exactly how much we're investing, but the return side is very difficult to nail down. So increasing opportunities to get that return just make sense. I'm going to have higher ROI if I increase my return and/or decrease my investment. And so this is what throughput economics is all about.
Lee: I think probably the short answer is you don't make a culture change, right? We see this all throughout history. Anytime one regime is taking over a population and try to force a cultural change, there's always the seeds of rebellion that are just under the surface there and that's happened all throughout history. Anytime we try to take a culture and force a change on it, it always meets with resistance and it never sticks.
I mean, just think about the word "culture." It's the belief system. It's the attitudes and the behaviors and they're often unconscious. They're just part of the fabric and part of the DNA of who the people are and of the organization that's made up of those people. So to try to force a cultural change is really, really a fool's errand.
When I'm asked about that, the thing that I like to stress, because just from getting hard knocks of my own in doing that, is that we realized in Agile that we know that people are intrinsically motivated versus extrinsically motivated. We also know that through a lot of research in the last few years that it's much more effective to actually enhance strengths and emphasize strengths than it is to try to remediate weaknesses, people's weaknesses.
Fortunately, if you're talking about an Agile transformation, a lot of those things are built in to Agile itself, the values and the belief system that's there which in turn produces behavior is actually baked in to the Agile Manifesto, the principles behind it and the things that evolved from that. At a team level, that's why it's very easy to have, I think, cultural change at a team level.
The problem I think in the cultural change and trying to have organizational cultural changes is something we talked about just like a few minutes ago which is that Agile is seen as something only that the team does, and it's not seen as a top to bottom transformational type of thing so you open end up with a clash of two cultures.
In order to have that cultural change, it really has to be something that is I think understood from the top to the bottom and then instead of trying to force it to happen, I think the most effective cultural change is one that's allowed to happen by the way that the environment is shaped.
An example of that is the reason I have a mortgage on my house. I don't have to have a mortgage on my house. I could rent. But the tax code is structured such that it is actually favorable for me to actually have a mortgage on my house for the tax benefits. The environment is there, nothing is being forced upon me, but the government is kind of engineered it to shake my behavior in such a way that I can choose something that's going to be better for the system and it actually works out for me. I'm intrinsically motivated to do something that works out for me financially, to have 2,000 square feet on a half an acre that belongs to me and it also benefits the system.
So I think finding some way to motivate people intrinsically, a way to play to their strengths and also benefits the system is really the key to having this organizational cultural change.
Shane: Lee, thank you very much for taking the time to talk to us today. We really appreciate it, and I hope you enjoy the rest of the conference.
Lee: Thank you.