Never Send a Human to Do a Machine's Job: An Interview with Steve Povilaitis

Cameron Philipp-Edmonds: Today we are joined by Steve Povilaitis and he's going to be speaking at the Agile Development Conference & Better Software Conference East 2014 down in Orlando and he's giving a presentation titled "Continuous Delivery: Never Send a Human to Do a Machine's Job." Thank you so much for joining us today, Steve.

Steve Povilaitis: Thank you.

Cameron Philipp-Edmonds: To start things off, could you tell us a little bit about yourself and your role at the company?

Steve Povilaitis: Sure. I'm an enterprise agile coach at LeadingAgile. What that means is that I work with organizations that are adopting agile across multiple teams and organizational levels, and addressing the challenges that come along with their agile adoptions. I've been working with agile organizations for the better part of the last decade in mnay different capacities. I was a software engineer, a software manager, and even before I got involved in the software development field I was part of the very agile organization called the US Army. And if you'd like, we can talk about how the military helped me to form my operational agility mindset.

Cameron Philipp-Edmonds: Absolutely. But, what led you to the idea of your presentation?

Steve Povilaitis: In my coaching experience, and in my overall agile experience, I see many teams, even high performing teams, focusing the majority of their work on the application development part of the delivery life cycle. And after that is when things fall apart because you've got this time-consuming, manual delivery process. If the program is what I call messy, and the organization just kind of accepts that messiness then that really negates the value of the agile process, because even if your team is delivering your stories and your features on time, you still have customers clamoring for new features or bug fixes to go into production. You still haven't realized the value of your software construction, because you're not getting those capabilities to your customer—which is the end goal.

Cameron Philipp-Edmonds: The title of your presentation borrows from a cinematic classic and a favorite of mine, The Matrix, and a quote from the movie: "Never send a human to do a machine's job." Were there other quotes from other movies that you considered?

Steve Povilaitis: Well, Cameron, there really weren't, because when I heard that quote, it immediately resonated in my head. This quote encapsulates the entire philosophy of continuous deployment and of the DevOps movement. It was perfect. I don't think there could be a more perfect quote.

Cameron Philipp-Edmonds: There are some people out there who are concerned that tools are making slaves out of humans and that instead of humans using tools to serve their purpose it's the other way around. Do you feel like that might be a problem too?

Steve Povilaitis: In this space, continued deployment and delivery, I don't think that's a problem. Quite the opposite. I think tools are liberating. They're liberating in the sense that they free developers and engineers to focus on the fun stuff, the stuff that really takes more of an analytical mindset. It frees us from doing all of the tedious, manual, lever pulling, and knob twisting of deployment that we were doing before. It liberates us from working in the coal mines of software engineering and leaves us focusing on the fun stuff.

Cameron Philipp-Edmonds: Great. I think that's a perfect view to look at it, very liberating. Your presentation also makes a rather humorous and truthful comparison that until your code is in production you're really just building toy castles in a tech sandbox. In brief terms, what are the steps to ensuring that you go from playing pretend to reliably and rapidly building and employing software?

Steve Povilaitis: I look at continuous delivery or continuous deployment as a continuum and there are certain ladder steps that one can climb on this continuum. First of all, the team should have some strong version control approach which would be a current generation shared version control systems that doesn't have an exclusive locking model. If you're using something like Visual SourceSafe, sorry, go back to square one.

Along with that, get teams developing on the trunk frequently and not having long release branches or individual feature branches or developer branches. Focus on committing frequently and have a continuous integration environment whether it's Jenkins or a non-open source tool.

Then start automating your tests. From there start automating your deployment and then, finally, start viewing your infrastructure as code as well. Start configuration controlling not only your source code but your very infrastructure.

Cameron Philipp-Edmonds: You just covered some ideas and some best practices for really taking it to the next level and climbing the ladder but, working back here a little bit, why should companies to look to implementing finished delivery in the first place?

Steve Povilaitis: This [continuous delivery] is the final frontier. Now I'm thinking of Star Trek The Final Frontier. [shares laugh with Cameron]. This is the final frontier of a lot of companies to fulfill with agile, the culmination of the iterative development process, being able to take the value that's produced during the iterative development process and then being able to automatically integrate, test and deploy what the development team has produced into production relatively quickly and pain free compared to the previous manual and error-prone process.

Cameron Philipp-Edmonds: We just covered some best practices and why you should consider it. On the flip side, what are some barriers to implementing continuous delivery?

Steve Povilaitis: One of the barriers that I often see, which is kind of ironic if you consider that these tools and processes are so liberating, is that to really make this work the developers and the engineers in the organization have to have what I call a stop the line mentality. And what that means is that when a new piece of code is integrated into the CI system if that code is broken for whatever reason, and I don't mean just broken in that it doesn't compile, but if the test fails, or functional testing fails, or it doesn't work in the test environment, then all development stops and it's all hands on deck at that point to get that build fixed before you go on and commit more code.

That's a big mindset change for developers, where often where they're just like; "well, I didn't break that build, it's not my problem, so I'm just going to keep creating my code on top of this broken build". That's really just exacerbating the problem. It would be better, if you're not going to help to fix the broken build, it would be better from an organizational standpoint if you just take the day off rather than keep committing code on top of a broken build.

Cameron Philipp-Edmonds: It's akin to accumulating technical debt.

Steve Povilaitis: Exactly.

Cameron Philipp-Edmonds: We've talked about some of the barriers here, but is it more challenging implementing continuous delivery pipe lines in large organizations or small ones?

Steve Povilaitis: I think generally it's more difficult in large organizations because you've got more moving parts, more rules, and more people committing code into the system and they might have more variation in the way that they have to deliver their code or interact with different customers—things of that nature. I think it's the nature of the beast that large organizations have more challenges.

Cameron Philipp-Edmonds: You're also a huge proponent of automation. You alluded to it earlier how that's liberating. Is there anything that shouldn't be automated and what are some ways to distinguish what should and shouldn't be automated?

Steve Povilaitis: I think any organization will find things that shouldn't be automated when the benefit of automating is outweighed by the work that is involved in setting up the automated tests and tasks that are part of the work flow. What I encourage teams to do when they decide that they want to invest in continuous deployment is to borrow from the Lean Six Sigma camp and do what is called a value stream map. Which is a process of mapping out, visualizing, all the steps that have to happen to get a new piece of functionality, a new capability from inception into deployment.

From there, look and see where there's waste, by waste I mean processes or activities that have a lot of wait time or rework because they're highly manual and error prone. Then, identify those areas and focus on automating them and iterate from there. Take the low hanging fruit where we can automate things quickly, and then focus on more challenging areas.

Cameron Philipp-Edmonds: Great. It's making it more digestible parts instead of trying to look at everything as a whole?

Steve Povilaitis: Yes, exactly.

Cameron Philipp-Edmonds: You've helped lead companies to agile adoption from large scale enterprises to internet start-ups. Does the size of a company affect their ability adopt agile or is it really more of a case-by-case basis?

Steve Povilaitis: I think it's on a case-by-case basis, Cameron. I've worked with some large companies that have had successful agile adoptions because they had a commitment from the senior leadership in terms of giving the organization the tools, training and support they needed to succeed. I've also worked for some smaller companies that had difficulty with their agile adoption, not because they weren't invested in it but because the nature of their work was so dynamic and emergent that it was a challenge to get them to fit into an agile methodology.

Cameron Philipp-Edmonds: Makes sense. You talked about this earlier, you spent time as an Army communications officer and paratrooper which you believe helped to hone your agile mindset. Can you speak some more on that and what your responsibilities in technical and operational agility were?

Steve Povilaitis: I was what is called in the Army a Signal Officer, which means I was responsible for communication electronics, radio systems, satellite communication systems and things of that nature and deploying and managing them in an austere environment. We had a leadership philosophy in the army based on what is called centralized command and decentralized execution.

At all levels in the Army it’s the commander or leader tht focuses on the what. What this person expects his or her team to do, then he lets his team, with his support, focus on the how. How we're going to get that done. I think that is completely analogous to the way that we do things on an agile scrum team. We have a product owner that, if they're a good product owner, they're focusing on the what. They're not getting stuck in the how trap. They're telling their team, "OK, this is the functionality that we need to deliver to our customer."

They let the scrum team figure out how to deliver that. Just as in the military we have what we call centralized command and decentralized execution teams, scrum and agile teams are the exact same thing. And it's interesting especially because folks always have a misconception that the military is this very hierarchical, command and control based structure but it's far more than that. Commanders give their subordinates a lot of leeway to do what they need to do to be effective and if they're not being effective, they raise their hand. Just like a scrum team in their daily standups might raise their hand to the scrum master when they have an impediment, it is the same idea in the military.

Cameron Philipp-Edmonds: To reverse this a little bit here, you talked about how it helped hone your agile mindset working in the army. Is there anything you know now that you wish you new back then?

Steve Povilaitis:  I think one thing that I've learned is that smart people have a lot of great ideas and sometimes the best way to get those ideas out is to delegate and ask for feedback. You don't have to an answer for everything. There's limited value in investing in a lot of planning for what is an unknowable future. Plan based on the information you have and go forward. That doesn’t mean you don’t plan, but plan with the realization that it will change. It’s like another great agilist, Mike Tyson, said: "Everyone has a plan until you get punched in the face."

Cameron Philipp-Edmonds: One of my favorite quotes. OK. Is there anything you'd like to say to the delegates of the Agile Development & Better Software East before they attend the conference and, of course, before they attend your presentation?

Steve Povilaitis: I’m psyched to see you at my presentation. Get out not just with your work buddies or those that you've traveled with to the conference. Go out and meet some new people and get some different perspectives. There are no strangers at the conference, only friends that you haven't met yet.

Cameron Philipp-Edmonds: All right. Fantastic. That actually wraps up our interview. Once again, this was Steve Povilaitis and he's giving a presentation at the Agile Development Conference & Better Software Conference East down in Orlando. His presentation is titled "Continuous Delivery: Never Send a Human to Do a Machine's Job." Make sure to check it out. Once again, Steve Povilaitis, thank you. 

Steve Povilaitis has successfully led agile adoption, engineering, and release management across a broad spectrum of organizations from Internet startups to large-scale enterprise programs. Steve focuses his efforts on integrating Scrum and kanban with XP engineering practices. He has been a decades-long advocate of operational and technical agility, honing his agile mindset as an Army communications officer and paratrooper responsible for planning and delivering military telecommunications capabilities in a highly dynamic and complex environment. When Steve’s not helping his teams navigate the agile waters, you'll find him surfing the calmer seas around his hometown of Cocoa Beach, Florida.