In 2014, Allstate embarked on a quest to exceed an already high bar for providing accelerated value by leveraging DevOps and Agile to transform the way they delivered software. Through third-party partnerships, they were able to improve the Ops side of DevOps and incorporate a new Agile methodology for software development. In this exclusive interview with Roman Dumiak, Director of Technology Innovation at Allstate, we uncover how he and his colleagues built a team dedicated to Agile principles and what the transition did for Allstate’s ability to meet their goals and objectives.
How long has Allstate been doing Agile?
We’ve been doing both Agile Scrum and Agile XP since 2014, and they are our preferred methodologies for internally developed solutions.
Why is that?
We were transforming the way we delivered software to move to more of a DevOps model. We engaged with third parties to provide guidance in moving to Agile. In the case of Agile Scrum, it was primarily around organizational and process changes. In the case of Agile XP, we partnered with a platform as a service vendor and additionally leveraged their ability to teach us how to do software development using the extreme programming (Agile XP) methodology.
When you made that transition, were you doing a combination of training internal folks and hiring external folks?
We started with internal employees first and did some re-training. In addition to that, because we were expanding how we did application development, we were also doing external hiring. Recently, Allstate dedicated a significant portion of the benefits from the 2018 Corporate Tax Reform to retraining and reskilling our employees in a variety of new technologies.
What are some qualities you sought/seek?
It's very important that we assess across three major categories.
- Technical/Execution: We're looking for people who understand the technical aspects of programming, so object-oriented programming fundamentals, algorithms, refactoring fundamentals, and just some principals around clean code.
- Test-Driven Development: The other thing that is unique to XP is that we strive for 100% test-driven development. People must understand at least the fundamentals of the idea of writing a test first and then write the procedure or code that will turn that test green later. It’s a big shift for a lot of developers.
- Pairing skills: We look at candidates’ ability to work in a pair programming environment where one person drives the coding at one time and another one is an active participant and vice versa.
The technical criteria seem a bit more objective, but how do you assess for the more subjective pairing skills?
Within that category, we have a total of 4 things that we score candidates on:
- Empathy
- Effective Communication
- Applied Listening
- Collaboration
Can you elaborate further on what these criteria mean?
Effective communication, applied listening and collaboration refer to whether as a partner, you can you do effective listening. If I'm speaking to you, can you repeat back what I said in a different way to ensure mutual understanding? Will you share your thoughts and perspectives?
Empathy is the ability to be aware of and sensitive to another person's feelings, thoughts, and experiences. For instance, if someone is learning something new and they are struggling, empathy means recognizing they're getting frustrated and need time to step away and relieve the tension. You can be a very effective communicator, you can be an effective listener, but if you aren't sensitive to the fact that your audience or the person you're speaking to is frustrated with your comments, it won’t work.
What is an example of how you observe empathy in the interview process?
Say you have to reschedule a call and the candidate responds, "Absolutely. I completely understand you're busy." That would be a sign that they have empathy. On the flip side, a candidate sends an email saying, "I can only interview Fridays after 5:00" and you accidentally send a meeting invitation outside of that time. If they respond with, "I've already told you that I can only do 5 p.m.” That's an example of being non-empathetic.
Empathy is the ability to put yourself in somebody else's shoes. If you're going to be working with a person all day long, you must be able to sense how their day is going. Are they having problems at home? Are there things that are stressing them out? Is the way that you're speaking to them causing them to become frustrated?
Outside of the interview process, what has transitioning to XP done for you? How has it benefited the way you've been able to deliver?
It allows us to deliver accelerated value. Because we're doing agile, we can iterate through solutions to see if they provide that value. And because we're doing paired programming, we can now deliver a quality solution at speed. Doing pairing and test-driven development minimizes the amount of time spent on quality assurance testing. It also minimizes the time spent on support. We spend far less time supporting code anymore because it's high-quality code by the time it gets released.
Are there any drawbacks that you've seen so far?
There's a high hurdle to being able to hire somebody with all three key skills – technical/execution, test-driven development, and pairing. It's hard enough to hire somebody with good technical skills. Adding to that somebody who's done test-driven development is even harder. When you’re also looking for someone who has effective communication skills and empathy, the bar gets even higher. The bar we're setting can be daunting for people.
Is there anything you would have changed about your process in rolling this out in your organization?
We’re now looking at ways to scale our interview process. For example, let’s say we have a 90-minute intensive hiring interview (evaluating all three skills), there are only a few people who are competent enough to conduct it. This creates a bottleneck to the entire process. To combat this, our next iteration will automate some of the technical aspects of the interview so we can assess and move candidates through the process faster without taking up too much personnel time.
Rolling out agile in your organization was a huge cultural change I would imagine. Is there any advice you would give to other organizations just getting started?
The best piece of advice I can offer is find somebody to partner with that can help you learn the ropes. Give Agile a chance to work the way it's supposed to out of the book first. There are a lot of reasons certain ceremonies and activities happen. Once you understand what those things are and their benefits, then you can make your decision on what it is you want to modify later.
