Cameron Philipp-Edmonds: Today, we are joined by Neal Huffman and he'll be speaking at Agile Development Conference & Better Software Conference East 2014, and his session is titled "Making Agile Work—with Eleven Product Owners."

To start things off, let me thank you for joining us today.

Neal Huffman: Thank you. Glad to be here.

Cameron: Can you start us off by telling us a little bit about yourself and your role at Apex Capital Corporation?

Neal: Sure, absolutely. I've been in the software space for probably over thirty years, literally. The first ten or fifteen was in a development role. The last fifteen-plus has been more in the product management, software development management arena. The first twenty years I spent in telecom and digital branch exchanges, central office development, digital loop carriers, fiber to the home. The last ten years I've spent focused on the enterprise software space, more in the utility billing, the integrated courts of justice arena, where they tie in all of the different sheriffs, jails, and courts activities. Then the last year and a half, I've been at Apex Capital -- it's a financial services company -- we're focused on the transportation industry. My role is really all about software development, and the delivery of solutions.

Cameron: What led to the idea of your session?

Neal: The last eight or so years, I've been helping the organizations I've been at transition to agile, and the agile model is really built around having a product owner work with a scrum team that builds a backlog of solutions and prioritizes them accordingly.

At Apex, we have more than ten product owners, and the way this company is built, we internally build our own software to run the business, and there's about eleven different user communities within the company that use the software, so every user community has their own needs and priorities. Basically, when I got here, they weren't agile and they were struggling with getting software out in a consistent manner. The user communities were frustrated. The software development team was frustrated, and so what we did was we went through formal product-owner training with all of the organization, from representatives from each user community.

We had eleven communities, and I'll go down the list: sales, underwriting, marketing, integrated services, legal, accounting, account executives, credit. We pulled in one or two users from each community, and this organization has about 200 employees, so it's small-ball, but even still, each of these groups had a valid component of software that they used to run their business. This business is growing significantly.

We trained them for two days. They got their formal product-owner certification, and then they said, 'Well, where's my scrum team?' I said, 'Well, we're going to share. I have one development team of about ten, and we're going to split those guys up, and we're going to support all of these user communities.'

That's what I've been doing at Apex Capital, is helping them formally move into the agile world, and also bring in multiple product owners in a way that works. That's really over the last year and a half, that's what we've done. We have two-week sprints, and I'll share more later, but we've made it work with multiple product owners. It's different than traditional, or somewhat traditional agile, and so I was pretty excited about it. I've seen it work in a great way in a small organization, and I wanted to share that.

Cameron: Fantastic. As you kind of said, your presentation is about the transition to agile as a company grows, and so my next question is, obviously if a company's doing something right and they're experiencing growth, why should they be interested in transitioning to agile?

Neal: That's a great question, and really what it goes back to is, and I alluded to it earlier: The reason I was brought in, honestly, was because the organization was growing but they were not able to keep up with the demands of the software to run their business. The frustration was, they couldn't prioritize things, they couldn't get things out consistently, the user groups were frustrated, and there was just a general lack of cohesiveness from the software IT arena to deliver software, and so that's what was really the impetus to say, 'What can we do different?'

Really, my background for the last ten years has been helping teams transition to agile in a way that works, and so that's really why I was brought in, to help them formalize, streamline, prioritize, and then deliver software consistently that works.

Cameron: Okay, now beyond giving anecdotal evidence, you also share with attendees how to avoid heavy layers of tracking and reporting that can weigh down fast-growing companies. Why is this important, and how can tracking and reporting be a hindrance to some fast-growing companies?

Neal: Well, for sure, more traditional software companies, at least in the waterfall model, they had a lot of documentation, and then they had a lot of design up front, and wait until we know everything before we build. Agile is kind of really broken that off from a way to build software, and really, I want to make sure that the audience knows that you still need to measure, you still need to manage, you still need to have metrics, but you can do it in a way that's really lightweight, in a sense.

Whereas before, this group had no reporting, now we actually are using a lot of our tools to do the reporting for us. I've become a fan of Atlassian. They have a great tool suite: JIRA, Maven, Bamboo, Confluence. It really is a suite of tools that helps you not only manage your design activities and your stories and your task, but it also helps you with the reporting on the back end. You can see trends. Obviously you can get your velocity on the sprint. It really helps you take away some of that burdensome management layer, because it's built into your workflow process, so it's not something you do after the fact or extra. It really comes out as a result of how you do your business. I guess my comment would be, you still need reporting. A lot of the developers don't necessarily like that, but you do it in a way that's supportive, so you can see what you need to do in the future, how you need to support. You've got to grow your support team, etc.

The bottom line is, you do need reporting, you need to make it lightweight, and you need to do it in a way that's constructive and supportive of what your goals are as a business.

Cameron: What peaks and valleys should companies expect when they are making the leap to agile?

Neal: What we've been challenged with, obviously, is just getting the discipline of being agile, right? There is a discipline involved in it. One of the bigger things we've struggled with is really getting the acceptance criteria defined in a story. Our product owners who were new to agile a year and a half ago, and they're getting better at it, but what we've found is we'll go in and estimate a story. We'll say, 'Hey, it's four points, and then when we start building it, we'll do our daily interaction but the product owner will go, 'Oh, no, I need it to do this. I need that button to do this.' We're going, 'Well, that's not in the story.'

One of the challenges is to really get that discipline of defining what the user wants in the software in a clearly-defined manner that allows the developer to build it, so that again, when you're done, the user goes, 'Oh yeah, that's beautiful, man.' We can say it's 'done, done, done.' For a year, we struggle to get that 'done, done, done' concept in our software.

That's one discipline, was the user stories on the agile, or the acceptance criteria on the user stories, and then the other area that we've probably struggled a little bit is the technical debt. We'll build something, we'll put it in a spread, we'll release it, and then there's aftereffects, right? The user comes back and goes, 'Hey, this basically works but ...' or 'this doesn't work.' Some of it is maybe, again, to some degree maybe a user-story issue, but it's that discipline of really breaking things down into small enough tasks and clearly defining them so that that technical debt doesn't get built up. What happens is, we'll raise a bunch of points, and all of a sudden, for the next sprint or two, we're fixing things, right? There's that part of it that's kind of a bit of a learning curve or a peak and a valley for us that really we've had to make changes to try and figure out how to do better.

Cameron: You kind of talked about the discipline and really having to alter your state of mind when it comes to transitioning to agile. How does a company know they've become agile, especially if they were already experiencing some levels of success before. Is it something that they just kind of wake up and they're like, 'Hey, we're agile,' or is it more of a steady transition?

Neal: That's a great question, obviously. What's interesting to me, and what I've seen is, when people in the hallway are talking about sprints, and people that aren't really in the development team are going, 'Hey, I've got this thing I need done, and I could put it in a sprint and plant it down the road.' We're going, 'Wow, man, that's how agile works, right? You have an item, you put it onto your backlog, and you plant it into a sprint.' That really, I've started listening, and even up to our owners -- we've got two owners of this company, and they're talking sprints and backlogs and priorities, and I'm going, 'Wow, man, we're agile.'

Cameron: There you go. Now, you have a wealth of information and a lot of information that hits really close to home for a lot of the attendees, so what takeaways would you like attendees to leave with after your presentation is over?

Neal: In my opinion, there is no silver bullet. It really still comes down to good people working together to collaborate to define stories and sprints and working through the iterations, and going through that planning process to get something built that's what the client wants. My clients are internal, but we have external clients that use our software, so at the end of the day there is a user community out there that is really important to work closely with. And agile for sure, in a web type arena, will work really well helping companies deliver solutions.

Cameron: Okay, now to get to some more questions about you: You have more than twenty-five years building innovative solutions in the software arena. Software in this industry has changed dramatically since you first started out. Is there something you wish you knew when you first started out that you now know?

Neal: Another good question. When I started out it was pure waterfall. I mean, we literally would go down through and write test plans on software that hadn't even been written yet. What we found ourselves doing was constantly updating those documents, and they were paper documents at the time, and so I think we were working ourselves toward agile all those years and didn't know it.

Really, to some degree, agile allows us to continuously learn and peel the onion on what really needs to be built as a solution. It allows you to react quicker. It allows you to do things in a manner that the user can see them quicker or the client or the customer, or whoever you're building the software for.

I guess, for me, it's been fun to be able to stay in the business a long enough time to see that evolution to where we can actually build stuff that can be done in a very quick manner. The software tools out there today lend themselves to an agile-type development paradigm. For me, it's definitely in a much better state than it was twenty-plus years ago.

Cameron: To wrap things up, is there anything you'd like to say to the delegates of the Agile Development Conference before they attend your session?

Neal: Yeah, I would like to encourage each of them to really bring their real-world experiences to the table. I attended a conference last November in Boston, and sitting at the table during lunch for a couple of days during our week was the best time to talk about real-world activities around agile and how to make it work. That's really where I was able to share my experiences with other attendees, and it was very engaging. I would encourage folks to, if they haven't tried agile [yet], to seriously consider it. Then if they have and they've struggled or stumbled, to really bring those stumblings to the conference and let's figure out a way to work through them. The conference is a great place to do that. I really had a great time last year, learned a lot, and shared a lot with my team. That's really my encouragement to the attendees.

Cameron: All right, well thank you. Once again, this wraps up our interview with Neal Huffman of Apex Capital Corporation, and he's giving a presentation at Agile Development Conference & Better Software Conference East 2014. Make sure to check out his presentation titled "Making Agile Work—with Eleven Product Owners".

Thank you so much, Neal.

Neal: Cameron, thanks a lot.

As both a developer and product manager Neal Huffman has more than twenty-five years of building innovative solutions in the software arena. Initially, Neal worked in the telecom industry and for the past ten years in the enterprise space—utility billing, courts and justice, transportation—helping transition organizations to agile while building PCI-compliant eCommerce solutions. Neal is ScrumMaster certified and an Agile Product Owner.