Steve Brandt: And welcome to another episode of Vitech Talks: The Podcast. I’m Steve Brandt, your host, once again, and I’m joined today by a special guest, and we’re talking — I’ll get into his intro in a minute — but we’re talking today about Agile Delivery methodology. Very exciting, very important in today’s day and age, especially in insurance and retirement benefits technology, we’re seeing more and more of this and the importance of it as we continue to move into the market, [and] the market continues to evolve. Our special guest today is Carl Katz. He just so happens to work for Vitech now as senior director of our strategic Agile Delivery. A little bit about Carl. Carl leads Vitech’s new Strategic Agile Delivery team and has deep Lean Agile program and portfolio management expertise, and brings a wealth of knowledge around Agile, Agile leadership coaching experience, as he has led three previous Agile at scale transformations. Most recently, Carl led the Agile program management office for four years at Everbridge Incorporated, which is a pioneering life and safety cloud-based SAAS software platform for the critical event management industry. He’s also led Agile development implementations for Tufts Health plan, [in the] Boston area, Cotiviti, and AmerisourceBergen. Please join me in welcoming Carl. Carl, great to see you and welcome to Vitech, and great to have you on the show.

Carl Katz: Thanks, Steve. Appreciate it very much.

Steve Brandt: Absolutely. And we appreciate you coming here, so let’s just kind of jump right into it, Carl. We’re talking Agile Delivery here. If you could kind of give the audience a high-level kind of tutorial of the basics of Agile, what it is, what’s the history, maybe start a little bit about your journey, [of] how you kind of got into it, but just kind of a basic description of Agile methodology, so you can level set with the audience.

Carl Katz: Sure, happy to do that. So Agile is an umbrella term that’s used in the industry and describes various flavors of software development techniques and project management methods. Some of those include Scrum, Kanban, Lean, and Extreme Programming. These are things that have been around for quite a while. It first appeared as a term, [Agile] first appeared as a term in the early ’80s, actually around 1986, [when] it first appeared in a Harvard Business Review article. It started to become popular more in the ’90s, but it really took off in 2001 when a group of technologists got together out in Utah of all places, for a meeting to try to figure out if there were better ways to do software development than the traditional Waterfall ways of working. The outcome of that meeting produced a short document that’s referred to as the Agile Manifesto, and [is] sort of considered the bible of Agile. It basically outlines four main values and it also has 12 principles, and it’s intended to serve as a flexible framework that teams can use to guide their particular software development efforts. And probably the four values from the manifesto that are worth mentioning are individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiations, and responding to change over following a plan. And the optimal word here is over, in those statements. That is to say that while there’s value in the items on the right, we value the items on the left more. And that’s just a way of saying that as we’re transitioning from very established Waterfall ways of working that got put in place in the ‘60s and the ‘70s, that as we try to move to more flexible ways of working, we’re putting more emphasis and value on the things on the left in those value statements.

Steve Brandt: Interesting. Very interesting. Anything that has the words what’d you call it? Kanban? I kind of call it can-ban, now I kind of know where it came from!

Carl Katz: Can-ban, Kanban, take your pick!

Steve Brandt: I just like saying it and the word manifesto, if it’s got a manifesto, it’s got to be good, right? I mean, that’s pretty cool. So very interesting, thank you for that. It really helps. I don’t think a lot of people realized how long it’s been around, since the ‘80s and ‘90s? Especially in our industry, insurance and benefits administration. We’re kind of laggards from a technology standpoint anyway. And so [I’m] not surprised that it’s not pervasive in our industry, but it’s certainly now becoming more and more important every day. So it’s great to see that we’re catching up with the times, and it’s really good to see that sometimes being a lagger is good, because I’m sure all of this methodology is tried and true. And it’s very well practiced. Sometimes it’s better to be a follower than a leader, right?

So let’s kind of get a little bit into the weeds here, because this is kind of really heady stuff that I think the audience will appreciate. There’s a lot of detail here, software methodology delivery, development, this isn’t surface stuff here. So let’s get into it and talk about, how does it work in practice? What’s the difference between traditional methods and Agile methods, kind of a nuts and bolts discussion? And I’ll tell you from my, my perspective, I mean, I’m new to Agile, as I just mentioned. And I kind of feel like Waterfall methodology is this kind of traditional, very rigid type of approach. And from the outside looking in, I see Agile is this more kind of loosely driven, orchestrated, I don’t want to use the word chaos, but there’s a lot going on, a lot of stuff happening that is all more loosely managed, but the end result can be more powerful. So it’s kind of, kind of a traditional corporate meets commune, if you will, society, you know what I mean? Kind of in my mind, but go ahead.

Carl Katz: I think the way that you just kind of described it is pretty much accurate. I mean, the traditional Waterfall methods, also referred to as Phase Gate methods, are typically thought of as much more rigid. Agile, as you were saying, just the name of that process suggests that there’s, it’s lighter weight. It’s more nimble. So I think you’re spot on with how you’re thinking about it. To add to that, what I can say is that Agile is as much a mindset as it is a process methodology. It really emphasizes teamwork, frequent delivery of working software, close customer collaboration, and the ability to respond quickly to changes. And so those things are all in contrast to the more traditional Waterfall project management, software development techniques that really emphasize upfront planning of all the work and then executing it in sequential phases that I mentioned, your traditional requirements, design, build, test, release. Those are all distinct phases that occur over a lengthy period of time and often result in missed market windows and/or customer expectations. And Agile was really created to counteract all of that.

At the heart of Agile is the Agile team, in contrast to traditionally large development teams used in Waterfall methods. Agile teams are relatively small, they contain five to 11 people plus or minus two. So you’ll have up to 11 people, maybe the average is more seven to nine people. An Agile team is a self-directed, cross-functional team. Meaning that it has all the requisite skills needed to design, develop, test, and deploy a software increment itself. That’s a pretty big change from Waterfall methods, where distinct teams are doing each of those things. Having a cross-functional team means that all software developers, testers, business analysts, PM folks, are dedicated to a team and work together in collaboration toward a goal. So by doing that, it results in fewer handoffs between departments, often siloed departments, and this helps to reduce delivery delays.

Steve Brandt: Yeah, that’s a big difference. I mean, where you are really empowering these Scrum teams to kind of do it and own it all, within that specific delivery that they’re working on.

Carl Katz: Right!

Steve Brandt: Great. So tell me about those team members. I mean, this is another thing about Agile. There’s these roles that are called different things, and then there’s similar roles from, there’s kind of newer roles, and then there’s the similar roles that are called…have different names. You know, the one that everybody jumps out, you know, the whole Scrum Master name.

Carl Katz: Absolutely. You’re hitting on a really important topic, something that’s critical to the nature of an Agile team. Particularly in the Scrum process, which is one of the most popular team-based Agile processes out there. It really relies on three distinct roles on the team. It’s a little bit of a misnomer, because there are more people on the team, but what I’ll tell you is that there is a role called the Product Owner, or a PO, who has deep customer market and product domain knowledge to help the team basically identify what are the product priorities in the features that the team needs to work on over time, to deliver the right product to the customer at the right time. And that PO plays a pivotal role on the team by helping to prioritize that product backlog of items for the team. There’s a Scrum Master on the team, and that basically replaces the traditional command and control project manager that we’re familiar with in a Waterfall setting. The Scrum Master acts as a servant leader and a coach for the team, to facilitate the various key ceremonies and events that enable the Scrum process. They’re there to also help coach the team, enforce good Agile behaviors, and just help the team improve over time as they move through their work and executing the work in these various Scrum events and ceremonies. They’re also there to remove impediments and blockers for the team, so that the rest of the team can just go and get their stuff done.

And then that brings us to what’s considered the third defined role on a scrum team, which is just the team. That’s how they kind of actually phrase it. But it’s a little bit, as I said, a misnomer, because it’s comprised of the remaining dedicated resources that you obviously need to create software. And this includes your software developers, your QA testers, perhaps your business or solution analysts. And unlike in a Waterfall method, in which developers only develop and testers only test. In an Agile team, it’s like I said, it’s a self-directed, self-managed team of peers that are all working together. No one is over anyone else. And so they’re committed to achieving the goals. And so where there’s a difference is that, in an Agile team, they want to be more flexible and committed, committed to doing whatever’s necessary to ensure that the team meets those goals. So as an example, if the testers are behind schedule, are in the weeds, so to speak, the expectation is that if a developer is done with his or her piece of coding and they’ve got capacity, they should jump over and actually help test. So that’s something that you don’t typically see very often in a Waterfall process.

Steve Brandt: Yeah, that’s a great explanation. And as you talk, it just continues to remind me of that communal-type approach, where everybody’s looking out for everybody else, let’s get [done] what needs to get done. We’re a team, it’s not you do this and you do this; we’re all in this together. And I think that really kind of jumps out in your explanation. You know, we don’t have a lot of time left right now, Carl, this has been great, but with the say, 30 seconds or minute we have left, just very quickly, what do you see when an organization tries to go to this change, what are the biggest impacts? What are the biggest things that they need to kind of look out for?

Carl Katz: It’s been my experience that transitioning from a traditional Waterfall process to Agile methods, it’s a significant undertaking, and that’s largely because there’s a lot, a lack of understanding I think both at the business leadership level, in a lot of these organizations, as well as some of the people that are trying to implement it. As a result, organizations just don’t necessarily approach an Agile adoption in the right ways. Those who haven’t been formally trained in Agile processes start to dabble by cherry-picking various one-off techniques that they may have heard about, that actually can be less effective [when] used in isolation within the existing Waterfall process. And that just injects a lot of ineffective and unnecessary churn into the organization, and also spreads misinformation and misconception about what Agile or Scrum is. And so it’s been my experience and great fortune to help figure that stuff out. And I think the appropriate response to counteract a lot of that is to ensure that you’re providing the proper training and coaching from qualified Lean Agile experts to your constituents.

Steve Brandt: It’s funny you’d say that!

Carl Katz: Well, that is why I came to Vitech and to help lead our new, Lean Agile center of excellence. We’ve got three other senior Lean Agile coaches in that group. And so we’re focusing on the delivery organization right now and trying to help with some of our client engagements, but over time, we’ll be working with the organization to promote good Agile behaviors.

Steve Brandt: That’s great, Carl, and we’re very happy to have you. You know what you’re talking about and what you’re doing, and that’s exciting now for me personally, and for Vitech as an organization. So thank you very much for that. And thank you for spending the time with us here today. It’s been a pleasure.

Carl Katz: Thank you, Steve. I know, this has been great. Really appreciate it.

Steve Brandt: Perfect. Okay, now it’s that time of the show for the Brandt rant and you know, today’s rant will be less of a rant and more of a tribute, really, to a person who meant a lot to myself in my life, as well as a lot of people in this world, this country, and I’m talking about the now late, great Bill Russell, who died at the age of 88 this past week on July 31st, and someone that I came to know as a young person. I’m too young — can’t say that very often — but I’m too young to have been able to see him play. I was born toward the end of his career, so was too young to experience it. But I want to talk a little bit about Bill Russell and for those of you who know him or don’t know him, he was a giant in the American sports scene as a basketball player in the NBA.

He was a giant off the court as a person who fought tirelessly for civil liberties throughout his life. As a player in basketball, he was the winningest team player, the winningest player in team sports history in America, and backed up by two national championships in college and an Olympic gold medal. The year he graduated from college, he went on to the Boston Celtics and won 11 championships in 13 years as their star player, two as a player coach, five-time MVP, 22 rebounds a game for his career and 21-0, in game seven, winner-take-all games. So this guy knew how to win. He was the first black head coach of a major American sports team, and he’s been inducted into the Basketball Hall of Fame as both a player and a coach, and also into the College Basketball Hall of Fame. That platform, however, what it really did was it gave him the ability to do what he was truly passionate about, which was fighting for equal rights, civil justice in America, as a black athlete in America in the ‘60s. And growing up in the ‘50s, he certainly had his share of brushes with racism, throughout his life. And he brought that experience into the Equal Rights movement of the time. He led the first boycott of a sporting event to protest racial injustice in 1961, when his teammates were not allowed to sit in a restaurant in Kentucky, they boycotted the game and flew back to Boston. He marched with Martin Luther King and was at the “I Have a Dream” speech, on stage with the great Dr. King. He stood with Muhammad Ali in protest of the Vietnam war. He was a pallbearer at Jackie Robinson’s funeral, and he continued his civil rights activities, up until the day he died, and was awarded the Presidential Medal of Freedom by Barack Obama in 2011. So he really did use basketball and he bridged his basketball life and his activism by using that platform to spread the message on behalf of millions while being unapologetic and unwilling to bend to the will of those who opposed his views, always staying true to who he was and what he believed was right.

He withstood the pressure, the threats, the vandalism that reached into his home and family, including one incident that actually had someone break into his home and defecate on his kitchen table, but he endured both on and off the court. He lived life on his own terms, never losing the power of his name, never selling out to anyone. In 2011, again, he was awarded the Presidential Medal of Freedom by President Obama, his greatest of all championships. Rest in peace, Bill Russell, your legacy will continue to improve all lives forever. Thank you. And thank you for listening to Vitech Talks: The Podcast.