2. What does ThoughtWorks Studios do?
Chad: ThoughtWorks Studios is a product division of ThoughtWorks that builds tools for software development teams. We talk about teams that aspire to be high performing and aspire to be great.
Suzie: The Head of Product, I kind of look after the vision and the strategy for each of our products. We have four products, all in the software space for development teams.
Chad: It's actually been a very good conference. We had a lot of great conversations. People coming by the booth from a -- like, "Hey, what are you up to? What are you up to?" I also think there were pretty engaging talks and I had a lot of good conversations with speakers. So I try to pull them aside and get a little extra.
Chad: So we gave conference to tackle a lot about Mingle, our team collaboration and project management, program and portfolio management tool. We're really going for at this conference just talking about how do people scale, what is a great way to scale agility, not just processes and things like that.
Obviously, the rest of our products, we have Go CD, which is open source continuous integration and continuous delivery server. We have Snap, which is continuous delivery and continuous Integration in the cloud, helping people with work flows, Githib to Heroko, Github to AWS, and then we have Guage which is a testing tool.
So primarily here although we've been talking about Mingle and little bit of Go.
6. Scale Agile. What is the scale thing? Everybody's doing scale. What does scale mean for Agile?
Chad: Well, what's interesting to me is that I think when people are talking about scale, they're talking about, well, work execution and how do you do work execution for a large number of people. When we talk about scale, which I think is a little different, we're talking about, culturally, how do you make agility go from just teams doing agile things to whole organizations functioning in a responsive way.
Jim Highsmith, who works at ThoughtWorks has written a book called, "Adaptive Leadership," which is looking at probably how do you help organizations look at the challenges in front of them and organize themselves to respond. We think if you look at things like a new book, "Lean Enterprise" by a bunch of ThoughtWorkers, and "Agile IT Organization Design" by Sriram Narayan, it's about focusing your organization and designing your organization towards getting value. That's what scale is about for us. Then work execution comes as a result of that.
7. How do you design your organization for value?
Suzie: I think there's a bunch of things that we've been talking about. I think one of the things we talked about is asking the right questions. So building the right thing, a lot of people talk about that instead of just building it right. I think you can organize yourself around value by asking those right questions and thinking about your process from the point of view of bringing value to your organization.
So not just a process for the sake of it and not just because it worked in one place, not just because it's easy to roll it out but is that process bringing the value from the highest levels of the organization down through this execution? That's kind of one of the things for us. We're building a tool. How do you built a tool that helps you with things that are kind of philosophical ways of thinking?
That's one of the things that we try to do with Mingle is bring those philosophies of agility down into something that actually is usable every day.
Chad: If you think about a learning organization and the organizations of learning and things like that, if you're going to actually experiment, if you're going to do customer development, if you're going to have rapid sort of continuous delivery kind of cycles so that you're putting out things and customers are responding, you then need to have tool support to function like that. Yes, it's a little bit philosophical but I think you can embody those values in tools.
8. Can I put a really difficult question? What's value?
Chad: You want to take that one?
Suzie: I think that really depends on your organization. So I think if you think about something like us, we work in this large organization, ThoughtWorks. We have three pillars. The first is about a sustainable business. The second is about bringing innovation to the software space. The third is about social justice.
For us, value could be in any one of those parts. We have to think about that. So I think value for a -- if I have a set of shareholders, maybe their value's very different than if I'm trying to bring smart thinking to the software space. But I think that's really where the important thing is when I say about questions is, what is it for each organization? What is value for them? Maybe it's money. Maybe it's not. Yes. I don't know.
Chad: I gave a talk at Agile 2014 in India. I'm talking about process monitoring and how a lot of times in software organizations, people love process. They love the design process. The process is often done without regard to the outcome. So outcome is really specific. You have a lot of people, people at conferences, luminaries telling you what your outcome should be, thruoghput, cause of delay and things like that.
Those are all great ways to think about problems but fundamentally, your organization's going to say, "I'm building a car and maybe my car software is -- if it fails in any kind of way, someone's going to die. So maybe one of my real value things is making sure there's few bugs as possible, right?"
That's not a throughput thing. That's not a cause of delay. I don't want to invite you to die is my supreme value.
Shane: It's a pretty important characteristic for a car.
Chad: Right.
Suzie: Right, right.
Chad: So I think it really takes the introspection of what you're trying to accomplish to figure out what value is for you and then processes. First, the work design starts from there and then processes and work execution come after that.
Shane: But most organizations start the other way around.
Chad: Yes.
Chad: I think the first is convincing people that what seems like an easy route isn't really easy because it's easy to open up a book and have someone describe to you some processes to follow or practices to follow.
10. Why don't I just buy a framework?
Chad: Yes. I think frameworks are good as starting points to understand the problems and problem spaces. What is good for people to -- when we go to organizations trying to help them do this, it's where the points that you're going to connect to your customers? Where are the points that you need to create a feedback loop? Where are the points -- feedback loops, we tend to think of them in very developer-centric terms because they're XP, right? Running the unit tests, feedback loops. You have feedback loop. But there are other kinds of feedback loops like, "Hey, I'm in a team that's in a big program of work. I don't like all the stuff you're making me do, Program, because it's making me slow." Where do you see those feedback loops, right? So you have to put in the right feedback loops at different points in your work execution process, again, to make sure you get value.
I think if you start from there, you say, "Okay. Hey, I understand the framework. I understand those kind of things”, start to build things and put in feedback loops so you can change what you're doing to be appropriate as opposed to buy this thing off the shelf.
Suzie: Yes. So from Mingle, we can definitely talk about that. It matches very well with what we were just talking about with scale. Mingle's been, traditionally, a team tool. We kind of think that that's really important that teams can work the way that they want to and they can do this feedback and adapt and evolve but we really appreciate the need for higher level reporting and visibility at other levels of the organization.
We have some new features coming out, they're in preview mode right now, around program and portfolio management for Agile organizations. One of our key features there is around dependency management. But I don't think it's traditional dependency management, we really thought about this in terms of peer-to-peer dependency management.
I have one team who's working with some other teams, how do those teams work together to resolve their dependencies and move the program forward, move that feature that they're working on together forward as opposed to some overarching body kind of pushing dependencies and managing it through scheduling. It's kind of a peer-to-peer, "Hey, can you help me with this?" "Yes, I accept it. Let's talk about that." Then visibility for the people who need to see these are the dependencies we have.
I think we've had a lot of good feedback in the booth, the people that we showed and our existing customers. So we're excited about it. That's for sure.
Chad: Another thing we're talking about is the Snap team just put out the beginning of a blog series today where they are talking about their evolution on container technology. So they're on a path to support Docker for Snap CI. They're walking through their journey starting with Open BC and what their next steps are will be a whole blog series. But they're writing that. That's really exciting for us to be able to support Docker in the cloud.
Suzie: Yes.
Shane: Cool. Well, thanks so much for taking the time to talk to us today. It's been really good. Enjoy the rest of the conference.
Suzie: Thank you, Shane.
Chad: Thank you very much.