Agile Leadership Podcast #4 This is Joe Kirk. I m the CIO for the Tennessee Department of Transportation. Welcome to the Agile CXO, Agile Leadership Podcast. I m your host, Jeff Dalton. This month, we re speaking with Joe Kirk, Chief Information Officer of the Department of Transportation for the great state of Tennessee. A lot of the states are starting to adapt the Agile. What caused you to decide that Agile was something you want to adapt for the state of Tennessee? The story is kind of interesting. I ve only been the CIO here for about four years and before that, I was actually working as a contractor in the project management office. One of my co-workers started reading about Agile. He came to me one day and had a really interesting observation for me. He said, I ve been reading about this Agile thing and Scrum in particular. He was thinking about software development. He said, I think that it describes about 85% of the way that you work. He said, I don t think that you have the discipline to learn the other 15%. It will only come naturally. I think you need to go learn this and we need to try it out. We re here as contractors which says something about the department that we sort of have that freedom as contractors. I was challenged by it. I started reading and we came up with a plan that said I would go get certified as a product owner. He will go get certified as a Scrum master. And then, we would do a project to get some experience, to be real honest, thinking we would have to leave the state in order to do it. Page 1
We had no indication that there was any interest on the part of the State of Tennessee in anything being Agile at that point. Again, this was about four years ago. After that, I became a product owner. He became a Scrum master. We had six weeks sprint. We didn t know what we were doing. We did long sprints rather than short ones. But at the end of six weeks, we had a product ready to go in production. It was something that the commissioner of transportation had been asking for and nobody had been delivering. We demonstrated it, had some good feedback. We went back in and did another six weeks sprint. At the end of that now 12 weeks, it went into production. Two weeks after that, I was called in the office of the chief financial officer. They asked me if I wanted to take over the department. Everything just changed overnight. What was the state s interest? There was none until we demonstrated it. Once we demonstrated, there was enormous interest in it. The second story I ve heard this week of someone coming in as an evangelist of Agile to the state and become the main chief information officer. That s not only a professional story but quite an interesting personal story. It was a real change for me. This is Nashville. Everybody is secretly some kind of artist here. If you re the lead singer of a band and you want your band to be famous, you re working at Starbucks until that day comes or doesn t come. Your LinkedIn profile doesn t say occupation: barista. That s not how you think about yourself. That s the way I was. I had much higher aspiration. I ve done a lot of other things in my career. It just sort of ended up here to fluke. My LinkedIn profile didn t actually say that I worked as a contractor. I was just doing to get through what happened in the economy in 2008. Things got rough. I needed to go somewhere. I was just biding my time, thinking I got to get into something better than this. All of a sudden, I was given this opportunity to fix the things that I thought was broken. At some point in our career, everybody looks around and Page 2
thinks, If I was in charge of this place, I ll run it really different. If I was king of the forest, I ll know what I ll do. And then, I got offered that opportunity. I handed a plan back to the senior leadership that was basically a plan to implement Agile across the organization. They read the plan, discussed them with me for a while and said, Okay, you can do everything that s in that plan. Sometimes people are sorry they opened their mouth but it sounds like you were all good for you. They ve been really happy with it. It s been a good thing for them. How many folks are engaged in Agile development. The IT group here is 117 people. The development side is slightly less than half of that. The scope of your Agile adaption, is it primarily on the development side or are you doing it elsewhere? No. Actually, we don t view it as a software development methodology. It s something that happens on the software side. We really view Agile in the broader sense of the word that we run the whole organization. Agile 2.0 type of implementations. Of course we started with Scrum. That was the easiest place to start. The thing makes sense. It s predicted. Once we got that side of the house rolling, then the attention really for the last six months or so and going into next year is on the operations side, on service delivery and support where it will be a lot more Kanban, and then you get into DevOps. There are lots of titles strung under the Agile umbrella. But for us, Agile is really the philosophical framework of the way we re doing the entire organization. What s been fun is to watch how that has begun to influence the rest of the Department of Transportation. The HR Department has been very involved with us in staffing up and building the organization. I always enjoy talking about Agile values because unlike waterfall methods, Agile is based on a set of common values. It seems like a lot of the state CIOs are struggling with getting those values to be understood and accepted. Things like fail fast, transparency and collaboration and face-to-face contact Page 3
and low documentation, all of these things that are famous about Agile implementation. How did you get your team to get on board with the values side of this? That s a great question because you re right. That s a good way to put it that it is more values based than a methodology. The first thing is that I got to live it myself and then the rest of our leaders got to live it. It s not a thing that you just go and take a class and study and, Okay, now I know how to do that. I was Waterfall yesterday and I m Scrum today. There are set of values and if you don t demonstrate them from the top, then the organization will not believe that they re true. I ll give you an example. First day I moved into my office, the prior director of IT had what I would describe as a big banker desk. It s a big imposing wooden desk. He s in the high back chair behind it and the people in front had straight back chairs with no wheels. I came in the office and I wanted to ask whether I got the loan or not. For me, my first step, 15 minutes after I walked in the door, was to push that table onto its back and shove it out in the hall. I brought a table in and stole chairs out of the conference rooms and I turned my office into a collaborative workspace. My office now has a standing desk in the corner just because I need to get out of my chair occasionally but my desk is really a table with six chairs around it and a couch over under the window. I started communicating that, If you ve got something to talk about, bring it in the room and let s talk about it. It s not a place where people need to be intimated about coming. That will be an example of me trying to live out Agile values. The big one though you said is the fail fast. If we want to give people the freedom to fail fast, then we can t punish them when they fail. Fortunately, our commissioner is a person who also believes in that. I ve been able to communicate in my team that it s okay for them to try something and fail. They re not going to find retribution for that because I ve shown them how I ve tried things and failed and gone straight to the commissioner and told them what I did and I didn t get spanked for it. I think that s given them some confidence that I will act the same way. Page 4
Anything you do on a regular basis to remind your team about the values and to keep them focused on the things that are important? Next week, my development director is taking his whole team Scrum masters, the programmers, anybody who s involved in the development side they ll be going to a state park for three days. We ll spend time going over their values together and doing some team building exercise, doing some planning together. And having them involved in that process, I think those kinds of events help a lot. The other is that we do not dictate the values purely from the top. While there are certainly principles in Agile that we value this over that, we actually have asked the teams to write their own set of values for the teams and then share those with one another and display them publicly. That s really helped a lot when they feel they have a voice in determining what those values are. The other area we see a lot of struggle with this is with the business of the agency customers. I do a lot of work with one state where they re really struggling to pull those agency customers in as product owners and to accept the notion of fail fast and short iterative planning and some of the things that are common in Agile. What kind of challenges have you had with your business customer and what are you doing to overcome them? That is the challenge. We continue to struggle with this until this day. In fact, when we get done with this, I m going to meet with one of our key stakeholders who is not happy because we can t give him the dates of everything we re going to do for the next five years. He wants it all laid out in a big chart. What he says, If we lay out everything that we re going to do build a road in a big chart, why can t you do that in technology too? That conversation continues. I can tell you the main thing that we did though that really helped, we did a complete transformation in the organization. I created a whole new org chart, all new job classes, everybody in the organization starting with me had to apply for their job. We had a lot of turnover, a lot of people who chose to go somewhere else. We had a lot of new blood into the organization. And so, at that point I hired my product owners out of the business. They are, for the most part, not IT Page 5
people or come from an IT background. I went and picked off some of the best assistant directors in the organization. My person who works in our construction products was an assistant director in the construction department. The person who works on administration was an assistant director in HR. I told them all these business experts who are really trusted by the business and said, You all will determine the priorities for IT. In the ways of the stakeholder, they set all the priorities on the things we re going to deliver to the organization. It s not well-received at first. The business unit said, Well, if they re there to represent me, why can t they work for me? The response was, Because if they work for you, they ll only represent you, and what I need for them is to represent the entire enterprise. I need to have all the organization come together and just say what s best for construction but what is best for the entire enterprise together and that will give us better solutions in the long run. Over time, that has helped significantly. Those people go to the staff meetings of the bureaus, actively involved in the lines of business and they understand what those businesses need. It s their job to figure out how we re going to deliver them. The things we re hearing a lot is partition for documentation by the agency customers. It s sort of a leftover from the days when they were doing a lot of Waterfall. And of course, there are some regulatory requirements for documentation. Especially when it comes to things like design and requirements and test plans and things like that, what s your view for how the reduced documentation approach to Agile, how does that fit in with the state government and bureaucratic expectation for having a lot of things written down? The first thing is I always challenge people to show me where it s written down. There s a lot of, people will say, We have to do this and we have to do that. If you re really pushed back, you ll find out that there s actually nowhere where it says you have to do that. That s just the way they always did. That will be the first thing. We just try to demystify all of that. Page 6
I think Agile gets a bad rep that were somehow anti-documentation. What we re anti is documentation that has no value. Everybody in state government has a set of notebooks somewhere in their shelf that were generated to months and months of effort and no one has looked at it in over a year. The documentation has no value. It s just a thing that they did and then it s gone. So, we would say where we are not actually going to use it, let s not waste time doing it. Let s build what actually matters. We re very big sticklers on documenting the code well or documenting how the decisions were made but not a big set of requirements that you have upfront. The other thing and I actually have one sitting here on my shelf, at the time I first came in in this role, I ve been working in a project that took five years to deliver and it had an 800-page specs and requirements that were done upfront. Well, in the course of the time we actually delivered it, the iphone was invented. Everything changed. All of a sudden, what they wanted on Day 1 is not what they want now. They actually wanted it to run out of the field. All of those requirements were useless because the technology was just changing too quickly. When we re pushing for less documentation, it s not because we hate documentation. It s because there s no value in gathering and documentation right now on what we re going to do five years from now. Let s just gather big picture story for where we re headed. As we get closer and closer to the day we re delivering, the documentation gets very specific. It s really nice to hear you talk like this because more and more these days we are starting to hear senior executives talk about documentation this way. It s been a real change in the business since I was writing code back in the 80s and when I was doing, of course documentation was a big deal. Nowadays, it s little less important. In lieu of paper documents or digital documents, are you using any particular tool sets that you really feel strongly or passionate about? Well, we use Microsoft s Team Foundation Server. I don t know if I feel passionate about it in a lot of things. We re for the most the part a.net shop. That s where we do our codes, repositories. There s value in Page 7
everybody working out of that one tool and it s okay. I think it works really well for the developers. I think it works less well for the product owners. We all work in it because it does support Agile and looks at the metrics of burn down of stories and all of that. We use that tool. I m not thrilled. We ve been doing some testing with LinkIt. LinkIt seems keep rising to the top maybe because they re a national company. I like a lot of things about it. We ve not really been able to get the whole organization to buy into it. I think the real value is not just for me to use it but for everybody in IT to use and be able to pass things back and forth to one another. I would say we re still working on one or two tool sets. TFS is one thing that we settled on. It s funny. TFS seems to be one of the more common tools out there. I always get a rousing not so much pretty much from everybody even though it seems to be the most common tool in the commercial sector as well. It s super common, maybe only second to JIRA at this point for Agile tool set anyway. Well, if you re a Microsoft shop, you re kind of foolish not be using it for your development side. It s just so integrated into the things they do. The problem is they just don t come out of the development side for us very well. Measurement. In the last 15 years, measurement has been a really big thing. We ve done a lot of work with different kinds of metrics, time, defects, testing, performance, those types of things. How important are metrics to your Agile team and what are some of the key things that you re using to understand the product quality and the product performance? Certainly within the teams that work on quickly on their delivery and stories on their burn down, all of that stuff is useful to us. I actually don t feel like we ve done a great job in finding the metrics that tell us how the organization is working, with one big exception, and that s customer satisfaction. In many ways, that s all that really matters. The individual metrics along the way are not nearly as important as what are we being told by our stakeholders. We have very regular meetings with them where we are going through our work and asking for their input and their measurement of how we re doing. Page 8
I think that s important but I ll have to admit, I don t think we re very disciplined today in our metrics. I think that as we move more deeply into the service delivery support side, operations people are better at metrics than developers are. I actually think that s something they re going to bring to the table that will help in the overall picture. How are you leveraging the more traditional Agile metrics? Are you doing things with Velocity and Burn Down? Are you managing it at that level? Yes, absolutely. In fact, we had a product owner who left and moved to another part of the business. I m filling in for her at the moment. It s very high profile and it s for the commissioner and the governor that I have to take over. The first time I had actually sat with the team and owned the product in four years, it was almost shocking to me as we went through the velocity of the team to have that moment where they go, There s the line. You can t have anything beyond that in this next two weeks sprint. I was like, Wait a minute. I need these other things. And they said, Well, something else comes off the table. We had to sit and negotiate. Everybody is sitting there with planning poker cards. I know how the process works but I hadn t actually sat there and had the emotional impact of knowing the line is drawn here and that s what you get. Actually, I was pretty impressed at how they handled that and how they protected the team and kept me from just shoving something in and getting them to say, Yeah. We can do that, when they know well and good they can t. What kind of sponsorship or support have you gotten from either the commissioner or from the governor? The governor, not as much. He doesn t see it at this level. He is seeing some of the things that we deliver. I ve been with him when we demonstrated things. For the most part, though he looks at it and says, Yes, that looks nice. I would say that he s down at that level of the technology. Our commissioner meets with use regularly, pays attention to everything we do, comes and meets with my folks. He s been very supportive. Our basic structure then is that we have what we call the management advisory committee. It s generally the senior team telling the IT what to go do. Page 9
Our map structure is that the product owners report directly to me. We meet every week and do our priorities which are then fed to the rest of the organization. Every other week, the three key members of the senior team, the financial officer or the chief engineer and the chief of our environmental bureau, they come meet with us and go through those priorities with us to ensure they are supporting the back of their group. And then, quarterly we meet with the entire senior team to go through the thing and to demonstrate everything that got delivered in the last quarter and to lay out what we re doing for the next. They re very actively involved in the prioritization discussion. everybody knows that we have their support. I think Well, that s fantastic. That s a great environment to work in. Yeah, it s pretty rare. We re trying to move as fast as we can because in government, people move. There will be a new government in two years and that means probably a new commissioner. Who knows what happens next? We re trying to get as many things in place for the future in the next two years as we possibly can. Yeah, there are people out there that don t think Agile is something we should be doing and I know a couple of them. I always tell my folks, I assume that the next commissioner comes in and says, I have a nephew who owns an Xbox and he would love to be a CIO. We got to put everything in place to keep that guy from tearing it apart. We re just about to the end of our time and I wanted to ask you just one more question. I ve been asking the CIOs, What s the business case for Agility for someone that doesn t know what it is? For example, in the state I live in, the governor is very interested in Agile. If I m the governor or commissioner or one of those folks, what s the business case for Agility? Why should we do it? Good question. The business case is that change is inevitable. The world is changing quickly. If look at the statistics on your classic Waterfall approach, you gather everything upfront and work for a long time and deliver it somewhere down the road, things will change. No matter what you re doing, things will change by the time you deliver it and then you ve had wasted energy on delivering things that no longer have any value. Page 10
You will also will delude yourself into thinking that you actually know when you re going to deliver. I can t tell you what I m going to be doing two years from today but I can tell you exactly what I m going to be doing for the next two weeks. I can give you good promises and actually fulfil those promises. By decomposing things down into smaller chunks, you actually will know that you re going to get what you say you re going to get and you will not waste time on getting things that in the end you ll determine that you don t need. You ve been listening to the Agile CXO, Agile Leadership Podcast. This month, we ve been speaking with Joe Kirk, Chief Information Officer of the Department of Transportation for the great state of Tennessee. Please join us next month for more Agile illumination from Agile leaders. The Agile CXO Podcast series theme music is written by Stephen Hiltner. Page 11