New School IT ™

AGILE vs aGILITY - processes don't win, people do!

System of Discplined Agility Inc. Season 1 Episode 5

Send us a text

What happens when the Agile methodology becomes just another rigid process? In this thought-provoking episode, we dive into the critical difference between "doing Agile" and possessing true agility as individuals and teams.

Drawing parallels to athletics, we explore how business agility resembles a boxer's split-second reactions or a hockey player's ability to change direction at 30 mph. These skills don't come from processes—they come from practice, muscle memory, and instantaneous coordination between perception and action. Similarly, your organization's true adaptability comes from people, not project management frameworks.

We trace the evolution of Agile from its revolutionary beginnings in 2001—when it offered an alternative to the rigid structures causing 70% of software projects to fail—to today's reality where Agile terminology often masks traditional command-and-control approaches with the same 70% failure rate of the 1990s. Like today, it's easier and in many cultures very much 'safer' to blame a process for failure than to adapt to change quickly. 

The heart of the episode showcases our team taking SOTA's agility assessments and discussing the results in real-time. This unscripted conversation reveals how trust enables honest self-reflection, how teams can identify and address performance gaps, and whether to focus improvement efforts on strengths or weaknesses. You'll witness firsthand how psychological safety creates the foundation for true team agility.

Whether you're leading a business or AI transformation, managing software development, or simply trying to make your team more responsive to change, this episode provides practical insights for building disciplined agility among real people—not just implementing another process.

Ready to assess your team's true agility? Message us on LinkedIn for access to the same assessment tools we demonstrate in this episode, and join us in two weeks for our season finale on building systems that guarantee transformation success.

https://www.linkedin.com/company/new-school-it/

Speaker 1:

Music.

Speaker 2:

Hello, this is New School IT. How can I help you?

Speaker 3:

Hi everyone. Welcome to Episode 5 of New School IT's podcast, agile vs Agility. Five of New School IT's podcast, agile versus Agility, tune into this episode to appreciate the big difference between agile as a company process and agility as a personal skill and what it takes for teams to develop it together. I am Roland, creator of Soda, founder once more, and a veteran business transformer.

Speaker 4:

Hi everyone, I'm John.

Speaker 3:

My co-host, john, is a renowned corporate leader and successful retired software entrepreneur who can make disciplined agility sound like common sense. Hi, I'm Nasheed. My co-host Nasheed is a veteran data technologist now helping organizations turn their data into the ultimate competitive advantage in their industry.

Speaker 5:

Hi everyone, I'm Ryan.

Speaker 3:

My co-host, ryan, is not only a seasoned sales executive solving digital problems for Fortune 500 enterprises. He also brings disciplined agility experience of a real-life martial arts teacher we can help. There are two main parts in this episode Less than 10 minutes to discuss some fundamental concepts around Agile, how it became the process framework of choice for software teams and how history is repeating itself right now. From there, we recorded our own real-life session to show how SOTA's self-assessment helps individuals and teams build discipline agility. Let's get started. Please hold.

Speaker 3:

Here are a few thoughts to set the stage. Agility how is it actually defined? It's the ability to change position quickly through multiple integrated movements. Two sports really bring this idea to life for me Boxing and ice hockey. Picture this you see a fist flying at your face and you duck instantly. Think about how many muscles that motion takes and how fast your eyes, brain and body need to connect in a split second just to avoid getting hit, and imagine how often the boxer had to practice those movements again and again to get that good and fast at it. Boxer had to practice those movements again and again to get that good and fast at it. Same thing in hockey Players skate at over 30 miles an hour, stop instantly and blast off again in a completely new direction. All of this within seconds.

Speaker 3:

What does this look like in business? By default, agility shows up most at the edges of your company. Sales has to react immediately to customer needs or you lose credibility. Marketing has to spot trends and act fast, or you look outdated. Procurement needs to adjust to changes in availability from suppliers all the time. Planning has to deal with unforeseen events that affect raw materials. The closer you are to the beginning or the end of the company's work, the more agility you need, because that's where external forces hit you the hardest and, just like in sports, if you stop practicing agility constantly, you lose your edge. Same goes for software. Ai apps and digital tools must have the same level of agility as the business that they support. An app that worked great in February might be outdated by Q4 if it's not updated. That's why I always say software is like fruit it's best when it's fresh.

Speaker 3:

Now you might be thinking but wait, we practiced agile. Doesn't that make us flexible? The answer requires a brief history to make sense, so we need to look at what was happening in the late 1990s, right before Agile was invented. Back then, the browser wars were raging. Buying, selling and making payments online exploded. The open source revolution was taking off, home computers were becoming normal and Y2K was going to wipe out every computer on the planet. Software projects were happening everywhere, yet 70% of more were failing. Does that sound familiar? The parallel to today is that then, tech companies were growing extremely fast. A team became multiple teams and they became departments, and instead of everyone sitting around a table, as they did when they were a startup, they used formal project management with handoffs between these departments and they relied more on rigid structures and heavy processes to scale their companies. At the time, no one had invented an alternative yet, but the 70% failure rate led to the Agile Manifesto, which was created by 17 software entrepreneurs, engineers and scientists in 2001.

Speaker 3:

The Agile Manifesto, large A, is four values and 12 principles. It was a philosophy, not a process framework, but it made software development successful. So it drove a major shift toward putting people, speed, flexibility and quality first over the rigid plans and heavy processes of the 1990s. And just to underline this again, the Agile Manifesto specifically says people are more important than process, important than process. That mindset helped Silicon Valley build the world's most advanced digital consumer products and platforms. The ones the entire world relies on every single day still Fast forward to today, agile in a lot of places is just the new project management, which is a process framework that treats people like resources.

Speaker 3:

Agile buzzwords have flooded the workplace. Teams talk about sprints, but they actually mean phases. They say release, but they actually mean milestone. They call it a backlog, but it's really just a task list. Project managers were rebranded as product managers or product owners, but many still work from rigid plans, fixed scopes and top-down control.

Speaker 3:

The big point of all this is a process doesn't create agility. People do so. If we become people-centric in the pursuit of agility, we need to also start thinking about trust. Why is that such a key ingredient for people to develop good agility? Trust has a number of pieces honesty, reliability, openness, mutual respect and others. But at work, there's one simple foundation technical competence. You wouldn't trust an accountant to fly a commercial plane. You wouldn't trust a graphic designer to conduct a criminal trial. Same thing here the developer has to know how to code well. The product manager has to know how to make an app great. The agile coach has to know how to build great teams. Real agility starts when everyone on the team is good at what they do. From there, you also need to build psychological safety. Why? Because otherwise I'm not going to admit when a change is needed, I'm not going to rely on your work. I'm not going to ask for help. I'm not going to give you honest feedback for the team as a whole to get better.

Speaker 3:

The list of examples is long, too long, but each item is amazingly powerful at preventing true agility. Without trust, people just stick to the plan, even if it's failing, because it feels safer to stay quiet and blame the process later. One other angle on people-centric and trust it can't be abstracted. Trust is built between real people, not between roles, titles or departments. Of course, scaling a business requires structure and you need roles, you need job titles, you need plans, you need budgets, you need org charts, you need all those things. Abstraction is a powerful technique for this, but trust happens face-to-face, not role-to-role. Okay, while tech companies scaled agility into trillion-dollar valuations over the last 20 years, non-tech companies are now facing their own turning point. That's why we built Soda To help teams move beyond rigid project processes that hold them back and instead know systemically how to do the right things in the right places at the right time with real agility as people.

Speaker 3:

Sota works alongside existing agile frameworks. It's built to strengthen the people, especially when the process feels rigid or the results feel fragile, by making agility a real practice skill, not just a buzzword. Starting to transition to the exercise here, they say you can't manage what you don't measure, and that's why SOTA includes agility assessments for individuals and teams, which we're about to demo. Each of us took two of them an individual one with about 50 questions and one that captures our own perspective on the team with about 30 questions, these assessments help us understand where our agility is strong and where we could grow it through coaching, training or more practice. When we use these in real life, the coach saw individual answers privately and then went about helping each person grow personally, but the team's collective results were discussed openly and used to co-create the team's development plan together. All right, let's switch gears and jump into our real-life exercise. Please hold.

Speaker 4:

So let's start by just talking about doing the assessments. How did each of us find it? Was it easy to be spontaneous and score? How long did it take? What did it provoke in terms of thoughts from each of us?

Speaker 5:

I could start first, because I'm just super busy week and super busy weekend with the kids so I couldn't get to it. I didn't actually have time to think about it because I'm like, oh shoot, roland needs this in like 20 minutes, so I wasn't thinking about it much and I liked it that way. Plus, I think one of the questions is about pressure. I thrive under pressure, I love pressure. It made me respond to it quickly and naturally and honestly.

Speaker 4:

How long did it take you in there, Ryan?

Speaker 5:

It took me about, I'd say, 20 minutes.

Speaker 4:

To do both assessments. Yeah. Yeah, I would say it took me about the same, I think. How did you find it?

Speaker 6:

The assessment was good. I wanted to make sure. I spent the time to do it and I've done a few assessments in different companies and you always approach it through a lens of do I answer this honestly or do I answer it the way I think someone wants me to answer it? No-transcript.

Speaker 3:

Yeah, and when we were doing this in real life, it was explicitly, strongly honored that the individual assessments would only be seen by the coach and that the aggregate would only be seen by the team. It's a by the team for the team thing, which is how it's powerful, because the team manages its own performance.

Speaker 4:

It promotes the autonomy of the team even further of thinking that if the team in general is having to be political about how it answers the questions or response to statements, then you don't really need to do the assessment. You don't have great agility, so start with that.

Speaker 6:

And I think that helps me in terms of framing the assessment. But even having received the assessment, claiming the assessment, but even having received the assessment, I didn't think about it as like a player coach type of assessment to align the team towards a unique purpose. Am I missing something or did no?

Speaker 3:

but I think it's interesting feedback. In the context of how we've administered these in the past, it was clearly understood that this level of agility just like a sports team it's not that you don't know how to be a good player, but for you to be a good player with 10 other players, you're going to have to have a coach coordinating all these things and making sure that weakest link in the chain is where the chain breaks. So if you're strong in one thing and not weak in the other, then I should be bringing up my strength in that area and vice versa. That doesn't happen automagically. So the role of coach is deeply ingrained in the approach to agility and in the context in which these tests were done in the past on these assessments, it was clear that it was going to be the coach and the team using the results of it to manage their own performance. It wasn't going to go any further than that.

Speaker 3:

Please hold but it makes sense for us to read a few of the questions. Right, and the answer is always, never half the time, always on a scale of one to ten.

Speaker 6:

One of the questions that jumped out for me for the individual assessment was others feel understood by me. I think that's a question that could be interpreted a couple of ways. Being understood and the feeling behind being understood could be something that doesn't necessarily mean that you agree Right, because I've been in plenty of situations where people they're making their point, I'm listening intently, but I completely disagree with the approach and they would say, and I would say others feel understood by me. For sure, they feel understood, but it doesn't mean you agree Anything else.

Speaker 4:

Jump out for anybody.

Speaker 3:

There were two that I thought were my favorite questions for us as a team. One was I enforce unpopular policies while maintaining team cooperation, and the other one that I thought was interesting is I point out small issues to my teammates to avoid big problems, and that also had a pretty big span among us.

Speaker 4:

It's interesting, isn't it? Big span among us. It's interesting, isn't it? Because those questions, those statements that you just went through, how you feel about those, in terms of how negative or positive they are, really is driven heavily by your own personality and your own sort of profile, totally. So you know whether you're deeply analytical, for example, of profile. So you know whether you're deeply analytical, for example, versus someone who's very big picture. So someone might respond to getting small things pointed out as extremely beneficial, whereas someone else might think it's a real pain in the neck. The individual one needs a lot of coaching and discussion. The team assessment, though it shows variance in the team that you can respond to really quickly.

Speaker 3:

Right. So my philosophy in building teams is not that you want to have everybody the same, because then the team is very strong in one area and usually not very strong in the other. So that balance of personalities, perspectives and creativity, that is very powerful. So you might have somebody who's a brilliant coder I'm going to use stereotypes here Quite introverted, who has a difficult time telling people no or pointing out small problems and things might become big, but somebody else who does. If the team trusts each other and they know, then those things don't get lost anyway.

Speaker 6:

That makes sense. So, as a part of the SOTA framework, this is one of the initial things that you do when you're leading a team is to do an assessment, to understand strengths and weaknesses.

Speaker 4:

Having gone through both assessments, I would be very inclined to use the team assessment as first, actually as a way of checking in with the team. How are we doing as we go through that evolution you just described, because I found my assumptions about the team and how we were doing and how we were working together actually were challenged by the team assessment. And that was very, very useful, because it then leads to a bunch of discussions you can have as a team about what are we going to do differently? Or, you know, are we just going to accept in this area we have a different point of view and move on. I found the team exercise extremely helpful. It's something I would do early in the process.

Speaker 3:

When we were doing these with larger teams in a real-life environment, developing real-life software, many of those team members, their initial response to the individual assessment was I thought this was great because it shows me behaviors that I should be developing. Whether you do the team thing on the individual assessment first, the individual assessment opens up some eyes about behaviors that are really important.

Speaker 4:

I can see that, and, roland, in your experience. How frequently should folks be thinking about taking these assessments, both the individual one and the team one? What's?

Speaker 3:

useful. A good agile cadence is quarterly for the bigger goals, but once a quarter to start with.

Speaker 5:

When you take it once a quarter, do you talk about it individually or talk about it as a team, kind of like what we're doing now? Some of the questions need a few questions you know like, or discussions around them.

Speaker 3:

So the way that we've done this in real life was, say, your team has 12 people, the coach, she would look at John's response, ryan's response, the sheet's response, et cetera, for 12 people and that was not shared with anybody. But she would sit with you and say, hey, ryan, how did you feel about this? Like. But she would sit with you and say, hey, ryan, how did you feel about this? Just do an analysis of it, an assessment. I'd say, okay, so you just assessed yourself. Do you feel that you want help in this area? Is this something you're interested in working on? How do we go about it?

Speaker 3:

And there's an individual coaching thing that happens to improve the discipline agility part. In addition to that, the responses of the 12 people there's a total score for 12 people that answered this Eight were at seven, one was at 10, and three were at four. Right, it doesn't tell you who answered what way, but it tells you that the team has a big spread. And, just like John just said, hey, there's a team with a big spread here. What do we do about this? Those conversations also happened in real life with that real team and it was amazingly powerful to see what changes that drove and how both discipline and agility improved in this group of 12 people because they were aware of their own personal preferences and limitations and they became aware how, as a group of 12 people, their individual contribution changed something. But talking about it openly between the 12 of them made them a more cohesive unit operated more as a team.

Speaker 1:

Please hold one team, one fight. We shine the most, and so does spotlight. Together we rise. Together, we play, laughing at each other day by day.

Speaker 4:

It might be helpful to move to sort of discussing the individual assessment a little bit further. We don't know each other's scores, as Roland talked about earlier on. We wanted to keep those confidential, but we have created an aggregated version that is anonymized. Our individual agility score averages at 77%. Why do we think it's that high?

Speaker 5:

Roland, you chose us all individuals Like hey, I think all these guys would be the first to dance Must have.

Speaker 6:

I think it's because we're more senior in our careers.

Speaker 4:

Yeah, it could.

Speaker 6:

And it might be because we're not building software. Yeah, right. Because if we were building software, there would be a whole different type of discussion happening around who's not doing what and where. We're kind of missing things.

Speaker 4:

Yeah, I get that. I took it as part of the seniority thing. I think if you've been around the block a few times, you just are a bit more flexible because life has thrown so many different things at you. Bit more flexible because life has thrown so many different things at you. For me. My personal journey was from very classic FMCG training, so lots of waterfall management, planning, forecasting, all that sort of stuff, and then, as I started to build a software business, really getting into agile and I actually found the assessment quite validating. I'd actually learned stuff from that experience of building software and that, I think, is one of the important things about Soda. Soda is bringing that experience of what you can get from building successful software into just building a general capacity within all sorts of managers to be part of that process. So I found that really quite interesting.

Speaker 5:

The seniority thing is definitely it and because, like I was thinking about your analogy, roland, where you know fighting. So I don't know if you guys have ever been on the ring, but I have. You know, I used to practice martial arts, teach martial arts. I used to practice martial arts, teach martial arts. And the first time you get hit, like in the face, your body is not prepared for that, no matter what. Like what you said, it's just like we've been through a lot. So once you get hit, it's just like one. I'm never going to get hit again because that freaking hurt. Then, two, you train a lot harder as an individual. Of course, there's a team aspect to it too. If you're training harder as an individual, you'll see the other people train around you harder too. After you train over 10 years, you earn your black belt, your second degree. Yeah, you become a little bit more agile.

Speaker 3:

I just heard all three elements of SOTA and that purpose Not going to get hit again. Yes, discipline I want to train as hard as necessary. Output I have the agility not to get hit again.

Speaker 5:

Oh, that's 100% it. And a lot of this made me think about that, because there was a question am I comfortable with surprises? And that's what made me think about it. And I was just like oh, I remember the first surprise when I was training. I was training so hard but then I got in a ring and then this guy just surprised me.

Speaker 3:

He was just like one jab and I was like boom. I was like wow, that hurt and never again. The word seniority means something in terms of career stage and title and accomplishments and all these other things, but the way that Ryan's coaching it is maybe the way that I would think about it too, which is just haven't had the opportunity to make mistakes and learn from it, or haven't had things happen to you that you didn't like. I'll tell you, parenting was one of the biggest lessons in that for me. You've got to pick your fights, and every parent that hears this is probably chuckling right now. We've all learned a lot from our kids, I suspect.

Speaker 4:

So let's look at a question from the individual assessment where there may be an opportunity to go from good to great, and that's the statement. I do both well, long-term planning and short-term actioning. In the assessment, two of us scored that 7 out of 10 and two of us scored that 8 out of 10. It doesn't matter who scored what. How do we react to that? Can we get it to eight plus for everybody?

Speaker 3:

My very first reaction. Rather than focusing on the things that are already high, I would want to focus on the things where we can actually develop strengths 80-20 rule. My instinct would be to focus on the areas that are low, where a little bit of effort, a little bit of discipline can generate a lot of gain, rather than trying to perfect something that's already pretty high.

Speaker 6:

You know, it's interesting A mentor of mine who mentioned this concept of strength-based leadership where for those of us, for example, who score really high on certain questions, maybe those are the people who help guide us around certain practices, and then those of us who score low in areas it's like all right. Well, the amount of effort it's going to take me to learn, fill in the blank, something I don't know how to do right is going to take a lot more effort than someone who's already really well versed.

Speaker 5:

Yeah, and Nasheed, I really like what you said because you could use this individual assessment to really match, like your analogy of rolling over the puzzle. So like if someone's not you know someone's score is really low and they admit they're not organized and that other other person's, like really super organized you got a team of 10 you could kind of match those people up, like sit this person next to the organized person. So if you use this as a, as a good tool and match people up, I think you know they'll play to their, to to people's strengths and lift other people up if they're not so strong in there. So it really depends on the attitude of the individual and the team.

Speaker 4:

Whether you want to go to that effort depends on how important that statement is to us as a team. I mean, if we all agree that it's extremely high importance, maybe then that requires work. Maybe it's about going from good to great in that case. The other thing that strikes me about low scores is that I suspect most people who've gone through their careers and sort of done a lot of personal development realise there's bits in their skill set that just aren't very good and have decided to live with it. To me, that's a valid choice too. Someone might say you know, I could do better at this, but I'd rather work on something else. It sort of fits with what you're talking about in the sheet. Please hold.

Speaker 4:

I want to throw one more at you, the biggest spread, where the scores went from 4 to 10, which is quite a big spread from this very closely knit team. The statement was we do not overpromise, and the scores range from four to 10. So four would be quite frequently are overpromising, 10 says we never overpromise. That's quite a range for us and it just struck me that that's a cry for help there. The folks clearly do think that either there are over promises made and again it probably leads to holding each other accountable, to holding each other accountable.

Speaker 6:

With that big range? How do we deal with that? That is quite a range. I'm trying to recall how I answered that question, I think. When it comes to over-promising, I think we're trying to hedge our bets a little bit and make sure that we don't let anybody down. I think that's how I hear that Some of us may have more ambition in terms of what we think we can deliver. I don't know. That is interesting, that we score that way.

Speaker 3:

My instinct would be to get real about. Okay, what was it that we have overpromised? And I think we have the level of trust where that conversation will be perfectly feasible, not uncomfortable for us, but not in front of an audience, right not on stage, because we're not actually staging this. This is not rehearsed.

Speaker 6:

We're having the real conversation, yeah we're all kind of learning each other, so there is a to your point. Is the? Is the effort to make this adjustment worthwhile?

Speaker 3:

what john said earlier. Sometimes you just accept it, right. Yeah, put on my team coach hat In this specific case. Here I would want to just make sure that everybody feels understood and heard. It's subjective, the assessment on purpose. So somebody feels like we're overpromising. Is this because you want to be on time and we're not always on time? Or is it because we're putting out work that's actually not good? Yeah, guys, anything else that we want to pack into this one, that's good.

Speaker 4:

I've got nothing.

Speaker 6:

I don't have anything else. Let's wrap it All, right, yeah?

Speaker 3:

All right, see you everyone. Bye, see you later. Bye. Please hold.

Speaker 3:

Okay. This conversation covered a few key parts of our self-assessment, not as theory, but as a real life example. We hope you found it useful and if it sparked your interest, just message us on LinkedIn and we'll share the full assessments with you. Here's one key takeaway A process, especially if it treats people like resources, won't make you great at software People do. Join us again in two weeks for our season finale, where we share how to build a system around discipline and agility that guarantees success with your transformation. As we say, don't let the system defeat your purpose. Until then, train hard, get fast, get strong and keep moving.

People on this episode