Uptake is building an Agile company. Not just an Agile approach to development, but an Agile company. Agile is more than a development methodology—it’s a culture. For Agile to truly define a culture, people need to first fully understand it, and then deeply believe in it. In the traditional waterfall methodology of development, you know exactly what you have to do in clear and concrete terms, but it doesn’t empower you. It’s relying on a system to do your work instead of people and their resourcefulness.
Agile relies on people. True Agile is empowering teams to do things for themselves, guiding instead of controlling. It’s instilling camaraderie in the culture of our work. It’s building an environment of trust where we share a problem and discover together how to reach its solution. The best way to ensure success in software development is to rally a team around a common goal—that’s what Agile is all about.
From Problem to Strategy
When I was little, my grandfather had a computer in his office. I was around 7 years old and fascinated with computers. One day he told me, “I’ll teach you how to program. What do you want to make?” I wanted to build a submarine game.
“Okay,” he said. “Where do you want to start?”
I thought for a minute and then said, “I want to look through a periscope and see bad guys.”
“Okay,” he said. “What do you need?”
“I need to put it on the screen.”
“And how will you do that?” he asked me.
I wanted a submarine game. But I had no idea how hard it was to make that happen.
Little did I know that I would be doing that same exercise with software development teams nearly 20 years later. We address this everyday: Here is this big problem. This is where we want to go. Now, how do we get there?
Agile is a buzzword, a label. When I coach Agile methodology, I ask my team to throw out the label. Instead, think of it as a more human way to deconstruct and solve problems. The question isn’t, “Are we Agile?” The question is, “Are we problem-driven or are we solution-driven? Are solutions or problems the catalyst for development? And can we react quickly to change?”
As human beings, we are motivated by why something we do gives back to someone else or gives back to us. Agile takes a more human approach to development in which the developers are looking for something to derive value from.
Traditional predictive methodologies don’t give that context. As a product manager in a traditional development environment, I would go to a developer and say, “You must do this, and you must do this because it’s your job.” The only tie to the work done is that you make money. And if the only value tied back is that you’re making money, you don’t have connection to that specific job. And there are a lot of places you can make money to get a job done.
As a product manager working in an Agile environment, I say, “Look at the data. Get a better understanding. Dive deeper. Get closer.” Because the better we know a system, the better we can make changes to that system and changes in the approach to that system.
Agile relies on people. True Agile is empowering teams to do things for themselves, guiding instead of trying to be the one in control. It’s instilling camaraderie in the culture of our work.
Above all else, Agile teaches you to get intimate with the problems you’re trying to solve, so you can learn, pivot, and solve. Agile is not about going fast; it’s about understanding how to do things with the smallest amount of risk possible. With that, you’re able to pivot and adapt more easily to changes, which of course results in going faster.
But you can’t create anything until you know the language.
A subject matter expert (SME) is someone who has real-world context who can join the team, someone who helps ask the right questions. As a product manager, if I tell the team how to do something, time is spent interpreting, and not understanding, context. It is far more inspiring to have someone step up and teach how to understand the context of the problems we are facing, rather than dictating what something is or how to do it. You can understand a problem intellectually, but when you know context behind it, you understand the impact. SMEs inject that context.
As a developer gets more familiar with the code, because they have that context, it becomes part of who they are and how they work. The closer we can get to the problem, the better able we are to understand it. We are naturally better at understanding goals together, and we are more motivated to succeed when we collaborate.
Agile at Uptake
I never built that submarine game with my grandfather; I bought a game at the store.
My team at Uptake can’t go buy the software we have in our heads; we have to build it (because we are creating something that does not exist, but that is needed in a big way). By starting with real needs, identifying real problems, asking the right questions and talking to the right experts, we are defining ourselves as leaders, as explorers seeking out the real, hard problems of our industry partners. We are working towards building the right answers in the right context.
There’s no way we all think about things in the same way, so if we don’t have exceptional communication and collaboration, there is no way to ensure that we can get on the same page. That’s extraordinarily important — to communicate constantly, to understand what we need and to hold coworkers accountable. We all know we are responsible for the code and the product that comes from our team. The responsibility that comes with Agile is as simple as, “Here’s the stuff you have to do, you decide how to do it.”
Agile is an idea. It’s a different way to think about problems, and it’s how we are approaching everything we do at Uptake. It’s truly a remarkable way to work with other people, a great way to decompose problems. Agile is explicitly transparent, so we see all of the problems we have to address in order to improve. The decision points we face are clear: Are we going to shove them under the traditional methodology rug, or are we going to address them in a way that will define us as responsible, professional and successful? The answer to this question, and the others posed above, will ultimately define the great technology companies of the twenty-first century.