While agile software development goes back more than 30 years, the concept of agile is being deployed across many parts of the business. Its advantages in delivering increased collaboration, rapid delivery, reduced cost structure, and improved employee morale are some of the reasons more and more companies are adapting the agile methodology across the company.
At a recent industry event, we discussed how Utelogy has deployed agile across its organization and we thought we’d share with you. It gives you a look into the company and how we’ve evolved over time to improve our ability to respond to your needs.
Feel free to watch the video or read the transcript below.
Transcript:
I'm Frank, and I cofounded a company called Utelogy Corporation, and we are a software-defined, audiovisual control management, and analytics platform. As much as I'd love to talk about that baby of ours, my fourth child, that company, I'm going to talk about Agile today. Agile is a great word, I hear it a lot, and I think about it every day. Only these days I think about Agile in a totally different context than you might consider in the software world.
I first learned about Agile in a scrum environment at my dining room table on Sunday nights. I married into a large family. My, wife has nine aunts and uncles, and she subsequently has 30 cousins, and about a third of them work in Silicon Valley, as developers, and quality engineers. Sunday nights at our table, big family dinners all the time, and so Sunday nights at our table are those kinds of stories.
What was it like in today's stand up, or this week's stand up? It was very fascinating, and I have been listening to those conversations for longer than I've owned a software company.
Thankfully, my founding partner Scott, is a software guy back to the space shuttle days. He was at Rockwell, in the automation of the space shuttle program, so he understood this from the very beginning.
Our development team, as you can imagine, operates in an Agile environment. We use Team Foundation Server, and my partner Scott runs that group, and the epic story, tasks, sprints, daily standup concept are what we have been doing from the beginning. Now it's allowed us to innovate at a rate that I think most of my competitors, respectfully for those of you in the room, don't necessarily, can't compete with. And I kinda love that. It's a little bit of a throw down to my friends.
For me, as a kind of an ADHD guy, an ideas man, an entrepreneur, I needed a way to lead a company that allowed me to be heard by a bunch of technology people, without them getting frustrated with me, or without them going out on a tangent.
We started the Agile methodology in all areas of our company as a way to flatten the company, so everyone can be heard. And as much as I love, and care about our employees, I too wanted to be heard, and deliver ideas in a way that can be ingested in a way that I will go out and talk. I've got a bunch of ideas just from talking today with many of you, and I will go back to the office on Monday, and I might put a bunch of these ideas out.
The technology team, they tend to, in my mind, in my view, come in two flavors.
One, the technologist, the developer that cannot be distracted from what they were assigned to, and so all I'm going to do is, frankly, upset them. ‘Here's Frank with these ideas’, and gosh darn it, and I can throw them for a loop.
The other, are the kind that love ideas, and they can very easily go off, and start coding on an idea. Well Frank had this idea, and I come back to the office a couple of weeks later, and instead of continuing on the product development path, they've gone on a tangent.
My partner, and the managers of those teams, "Hey Frank, come on, stop talking to the dev team.” But when we deployed the Agile methodology in our organization, it allowed for us to come with ideas, come one, come all. If an idea fits neatly into the epic, it can be turned into a story, and then it can be assigned a priority, and fit into a sprint, or sprints as the story requires.
That has created the most profound effect on our team from a cultural perspective. It's flattened our organization out, everyone is heard from the bottom to the top, and we can innovate much, much, much faster.
Everyone participates in the prioritizing, everyone participates at a minimum in the story, and it's pretty good.
That was my problem, the ability to bring ideas in without upsetting the development cadence, and it's really, really worked out in a great way for us. It allows us to have the conversation with the various teams, but when we started bringing this down, we said, "Well, we don't want a manager to run a standup," because the manager has to be accountable to the team, just as much as the team has to be accountable to the manager.
We have, in our sales team, our first year right out of college inside salesperson, Luc, and he's running our sales stand up every morning at 7 AM, and it's been awesome for him. It gives him the experience, without having to have the responsibility of making decisions. But his job is to ask the fundamental questions that we're asking ourselves, that we're holding ourselves accountable on that sales sprint. In our case, in sales, it's a monthly sprint. He's taken the minutes of each meeting, and then he's charged with removing any blocks.
If there's a block on the project side, or the support side, or a contract side, Luke will have to send an email out, and try to get that block removed. That carries through our entire organization. Our marketing director is scrum master for the operations team, and our operations is deployment, support, and training, and our VP of operations is the scrum master for the quarterly Sprint on the eTeam. Our entire organization is run from an Agile perspective, and it really has gone a long way to flatten it.
Everyone feels like we're paddling in the same canoe, if you will, and you know when someone's not paddling. It's pretty easy, and no one wants to be the guy, or gal that's not paddling, so everyone feels heard, they feel understood, they're bought into the project, they're helping to prioritize, and everyone's paddling.
I cannot underscore the profoundly positive effects that the Agile methodology has had, not just on our innovation, but on our company as a whole.
By its very design, it promotes a very dynamic ideation process. Agile works, supports the collaborative nature, and change in doing business, and if you're not innovating, and changing rapidly today, it seems like the pressures is never-ending. We actually now seek partners that run their companies, and organizations in an Agile management format, or methodology if you will. We just brought on a great partner in Australia, AVT Distributors. Outstanding outfit, I know Paul knows those people, they run their entire operation in Agile, and it was like finding another human on Mars, it just felt good, it was a good cultural fit.
It also gives our customers the flexibility to make changes to the projects that they embark on, and we used to follow, on the project side, the relay race method, right? Where I do this part, and then I handoff this part to you, and you're going to do your part, and then it gets handed off to you, and you're going to do your part, and by the end of the project, because it was so well-planned on a project schedule, everything's going to dovetail perfectly, and it's just going to be brilliant.
Well, it may be me, but I never experienced that nirvana of planning a project, and ending up a year, or two years, or six months later, and it was just flawless. The Agile methodology in a project basis, allows for the customer particularly to have different ideas, or understand, come to new levels of understanding as their project unfolds, and it allows our company, and our partners to respond to those new levels of understanding without bonking our head going, "Oh gosh, another change, this throws the whole thing out," because we can divide a project into Sprints, and it really becomes a win-win, and we end up with that, "Our project," yeah, you may own the project, but during the project, it's our project, and it really fosters that team environment, and the outcomes are profound, and positive.
It does remove the unfounded, and frankly unrealistic optimism that comes with the idea that I'm going to plan out the perfect project, and so that's exactly what happened in a recent project of ours. It was a global enterprise, and they were building a new operations center. It was Shen Milsom & Wilke, out of DC that designed the project, but they knew we were operating in an Agile methodology. This was actually a technology company that we did this for, and they wanted to add a command-and-control center to manage a new product of theirs.
They had little experience in command-and-control, and it was very large-scale, 100 seats, 3 large video walls, much bigger than this room, and then 30 war rooms surrounding it, but they didn't know how their flow was gonna work in this environment, and we hadn't worked with some of the partners. One of them was Barco by the way, they were great to work with, and it was a bunch of different technologies. Everyone was feeling around on how to pull this off, that can be a recipe for disaster, and finger-pointing, or it can be a recipe for awesome collaboration, and a profoundly beautiful outcome, and it was the latter.
They were partners of Diversified & McKinstry, out of the Pacific Northwest, and Utelogy, and a few other manufacturers, and then the partner, and because they were a technology company, they totally understood Agile as well. They weren't sure how many rooms were going to be used, they weren't sure how people were going to interact with the systems etc., but they knew that they needed to monitor the growth, and of this particular product. It was because it was an operations center, when there was an incident, they needed to be able to parse the information out to the different war rooms associated with this, different seats for troubleshooters etc.
The point is, that we operated in a process, and a methodology that encouraged agility, and it turned out that the entire team was able to respond to opportunities as they arose, and note that I refer to them as opportunities, because when you are operating in that kind of managerial paradigm, it's an opportunity, it's not perceived as a negative. If it is a negative, it's black-and-white, it fits the epic, or it doesn't, it gets prioritized by the team, or it doesn't, and it's simple, simple to respond to.
The twist in all of this, and it's the only shameless plug I'll make, is that our technology at Utelogy, a software defined, audiovisual control management, and analytics platform, in and of itself, allows for an Agile world after your project is done. If you want to learn more about that, or ask me any questions about Agile, and what it's done for me, the ADHD CEO, I'm very happy to talk about that, thank you for your time.
The Q&A:
Speaker 2: First of all, I have to say, I do not know Frank, so I am not a plant, but everything that you have said is very much true. In our organization, we adopted the Agile scrum methodology back in January, and as an IT department, that does not create software, we do the typical things most IT departments do. It has encouraged us, and allowed us to actually move through just enormous amounts of work in an organized manner, in a manner that is very open. You can tell who's swimming, who is not, and it's just nice to hear somebody else is on Mars, too.
Frank: Yeah, and I'll tell you something, one of the most fascinating things for me, so details are elusive, right? Frankly there's only one job I could do in the world, and that's be a vision guy. I'd get fired pretty ... I'd fire me pretty quick, if I was had to be detailed, and the Agile methodology allows us to deal with the details later on in a project, right? I get to focus on the epic, we all get to focus on an epic, and then a story, and then only in that story do we start really getting into the details.
It's easy to deal with ... You do gotta get into them, but they come in smaller, more manageable chunks, and less fatiguing, at least for me. Thank you, yes sir.
Speaker 3: What methods did you use to train your teams in Scrum, and how long did that take?
Frank: We have a vice president of development, and a CTO, and they have a training method, it's like a package that comes with TFS, it talks about Agile, but the best training method we've had was with different partners, that we know, that we work with. We actually do a, God, it's eluding me now, but like an exchange program, and so we had the COO of one of our partners here in New York City, fly out, and talk to our team about what they were doing. It's probably a bastardized version, it's not Scrum, it's not a one particular way, we use TFS to manage it, but it was mentorship really I guess is how I'd say it, yeah.
We've been doing it now for two years throughout the company, the dev team, since inception 10 years ago, but the rest of the company, two years, and 6 to 12 months to really start getting into it, and now it feels weird if we're not engaged in an Agile.
Speaker 4: I guess, I don't know what the company size for Utelogy is.
Frank: We're about 50 employees, so we're pretty small.
Speaker 4: There's even a certain level of agility there in terms of dictating process, right? A shift to a new process. I guess where I'm at we've done some groups, the current group I'm on, and a very small portion of a larger technology group, are trying to do some things with Agile, and it's tricky, because we still have so many other systems we still have to report into, and document, and process, and ServiceNow tickets, and whatever, all these other things, so how do we, I guess it's not a matter of like ADHD, but it's a matter of we don't have the ability to focus in one area, and divert our attention, so I guess do you have any advice?
I know that's not necessarily something you experienced directly, but ...
Frank: Yeah, well I don't experience that directly, but I do have a bit of advice on that. My experience with larger companies, is that a team is like a small company within a large company. It may very well be that you've got to conform to a process that's in place, right? It's very hard to turn an aircraft carrier, and that's the benefit of being a small company, although you'd be surprised, even at 50 employees, it's sometimes hard to change.
If it were me, and I'm addicted to Agile now, and I was part of a larger organization, I would do everything I could to document the total cost of ownership of the process, as well as the ROI, and I would keep feeding that up in a, managing up, that's a delicate thing, and hope that the message got heard, but at the same time, I don't think you're going to be able to get away from assigning the tasks of, "Yes, we've got this super efficient Agile team here, but we've got these 13 things we've gotta do every Sprint to feed the old data monster," and that just may be something you have to contend with. Good luck with that, thank you very much everyone.
