Practicing Agile Development Principles
(without being tied to one methodology)
Tim Hickle:
So thank you all for joining us today. I’m really excited to have this conversation. Randy and his team at level 12 have been amazing partners for us here at Woven. And something that through the content webinars we’ve done in the past, I’ve gotten a lot of questions from engineering leaders about Agile development implementation.
And candidly, I’m not very smart about it. So I wanted to bring somebody on who’s a lot smarter than I am and has a lot more experience running Agile teams than I do and Randy is, I think he’s got a lot of great insights to share with everybody here. So I am really excited to hear from you Randy, and I’m going to spend most of my time being quiet and listening and learning from you.
But I want to kick it over to you so you can give a little bit of background about who you are and what you do at level 12. And what’s made your team so effective at running an Agile shop
Randy Syring:
I’m Randy Syring I am, as the slide says, the Chief Executive Developer at Level 12. We are a custom software and data development shop. We serve customers who need custom software or custom data solutions. And they come to us with a variety of problems, everything from helping autonomous drone systems, or helping or helping to do autonomous, autonomous inspections with drones, to, you know, building back ends for business processes, like you find it just about every business. So we have a pretty broad spectrum of things we do from a technical perspective.
And from an software and Agile development perspective I am not your typical business leader. I don’t think I really didn’t ever want to be in business really. I just wanted to build good software. And as I had more and more clients, ask for additional work, I brought on more team. And it just kind of developed over time that I realized there were certain things that I was doing to make us successful in software development where I felt like, as I was out in the community, and even talking with customers who had had bad experiences previously, you know, I was recognizing a pattern of how we were doing things.
And so I started I started thinking, “there must be somebody else out there who’s seen the same patterns.” And lo and behold, Agile development was out there, this is probably, I don’t know, 10 years now, when I started to realize, wow, there’s this Agile thing, and they’re talking about the exact same things that I’m that I’m feeling internally.
So I wasn’t exposed to Agile and then kind of set out to implement it. It was more like I was already doing it because I felt like this was just the way to do good software development. And then I and then I got exposed to Agile and realized there’s people who have actually thought about this have, you know more experiences than I do and they were able to articulate the things that I was seeing and feeling much better than I was able to.
And so we just continue to build on those principles that worked for us in software development in delivering things to customers, and then just continue to learn and grow and change our processes. As we realized that we needed to change them, which I think is one of the things I’m going to try to focus on here today in terms of a more Agile, Agile.
If you’re doing Agile, well, your Agile should probably be changing over time, and not be very rigid.
So we’ll get into that later. Hopefully, that is a good introduction that I leave anything out.
Tim Hickle:
I think you nailed it. It’s crazy to think that maybe if we’re if we’re actually going to be Agile, we should be changing and adapting over the course of time seems really intuitive, but it’s really hard and practice. So hard in practice. Yeah. So Let’s go ahead and dive in. I know that you’ve got a lot of thoughts on the subject.
Randy Syring:
Let me start out by making a really important distinction here that’s going to help us understand what Agile is and how Agile works, and that is principles verse implementations.
One of the things that I realized as a business owner is that my team would function more effectively if they understood the reason why I do things, as opposed to just how to do them.
Let me give you an example. We have a checklist application that we use, level 12 to help us with very various things like onboarding. When we onboard a new employee, there’s a lot of stuff that we want to accomplish with them. There’s a lot of accounts that need to get set up. And trying to do that ad hoc is very error prone.
So I went out, I looked at a bunch of different checklists, apps, and I ultimately picked one and I told the team to use it. Over time, I got some flack back from some team members because they didn’t like the app. It didn’t do this or didn’t do that. And you know that it wasn’t that they were incorrect, it’s just that I had a reason why I picked that app that I realized I hadn’t shared with anybody.
And so the reason for picking that checklist app was because as I read about how to do checklists and how they are successful or unsuccessful in organizations, and one of the key principles that I picked up on was that checklist will usually fail in an organization when they’re not easily updated to match current practices. So when I was looking through checklist apps, the one thing that I was really focusing on and optimizing for was how easy is it to edit a checklist if it needs to be modified.
The tools that I chose had some rough edges, but it did that one thing really well. And because of that, I wanted to use that app because I, I felt at a fundamental guiding principle level that was going to be more successful for level 12 than another tool that might be a bit more shiny, but missed that core principle.
So one of the things that I needed to do with my team was explain the principle to them why we were using that which was more helpful for them to understand why we kind of use the tool that had the rough edges, but also if they wanted to go look for a different tools like that, they would be able to not miss that guiding principle and say, “oh, this one’s shiny, but yeah, it doesn’t have that ease of ability to edit.” When I could explain the principle, they still may not like the tool, but they understand why it’s essential that we use that tool. And if they want to change the tool, they’ve got a they’ve got to satisfy that core guiding principle before they pick a different tool.
The principle ends up being more important than the implementation. Does that seem pretty clear? to us so far?
Tim Hickle:
It seems clear to me absolutely. I’m excited to dive deeper into that. I’m thinking through if I have questions on that because I know that is a focusing from a management side on the principles behind something is so important. So crucial. I’m glad you’re you pulled out that distinction.
Randy Syring:
So that the reason I pulled it out is because this is essential to understanding Agile development; what Agile is and how an Agile development team remains Agile itself. So one of the real difficulties with Agile development currently is there’s a bit of semantic diffusion going on.
Semantic diffusion is kind of a fancy phrase, but it describes when a word that is used by a person or group has a really good definition, but then it gets spread throughout a wider community in a way that weakens that definition. As the definition is weakened, you begin to lose the actual real substance of what that term meant originally, and the term in itself kind of becomes useless.
We see a similar principle in some products like Kleenex. Originally Kleenex was not what we call tissue paper. It was a certain brand of tissue paper, but it’s become used so frequently that it’s now it’s synonymous with it. It’s kind of the same, except that in Agile instead of it still being tissue paper, it’s been watered down in regards to what Agile originally meant.
I think it’s really important first to talk about what Agile is not. And this brings us back a little bit to principles, verse implementations.
Agile is not an implementation. It is not a methodology. It is not a framework or a process. It is not a specific way of developing software.
It’s really important to understand that the implementations that we see out there, whether they be Scrum, or Kanban, or XP, which is extreme programming, or SAFe, which is a more of an enterprise Agile development. All of these things are, these are implementations. These are ways of potentially doing Agile development, but they’re not Agile in and of itself.
For example, you could have somebody practicing Scrum, and a pure form of Scrum is likely going to be Agile. But you could have people practicing Scrum in a way that was not Agile. Agile is not Scrum.
So while the best Scrum will be Agile, Agile is not Scrum. It’s a set of values and principles.
Agile is a set of values and principles that were defined in what’s called the Agile Manifesto. And you can Google that I didn’t want to put it on the slide because I didn’t want to get too much into all the specifics of the values and principles of the Agile Manifesto. But you can bring it up.
There are ultimately four values and 12 principles that define an Agile belief system. Agile is a belief system, not the practices or the implementations that have flowed out from that belief system.
The reason that this is kind of hard, and the reason that the semantic diffusion has occurred is because practices are visible and values often aren’t. It’s very common for us to look out to people, to people or to other organizations or potentially to other teams, in our organizations and look at what they’re doing, and then copy what they’re doing.
But if it’s not clear that there’s a set of values and principles behind what they’re doing, we could very much we could end up being in a situation where we have copied the practices, but they don’t have the heart. We’re missing the heart of why they work for that team.
Our team might be different enough that those same practices don’t give us the same benefit.
Tim Hickle:
I love that that’s, that’s so valuable. And I think that’s something I’ve recognized in every aspect of my life, right? It doesn’t matter the motion that you’re going through is not is not important. It is why you were doing the motion and the desired outcome of the motion. I love that distinction. So I’m excited to dive deeper.
Randy Syring:
Okay, so how do you make sure that the Agile things that you’re doing don’t become rigid?
Pulling one value and one principle out of the Agile Manifesto here, value number four in the Agile Manifesto:
- We value responding to change over following a plan.
And Principle number 12:
- At regular intervals, the team reflects on how to become more effective and adjusts its behavior.
Built into the Agile values and principles is the sense of reflection and adjustment. We want to have that sense of reflection and adjustment, not just about the software we’re building, but also about the Agile development practices that we’ve decided to implement that have flowed out of our values.
Let’s talk a little bit about what this might look like. So if we move to the next slide, we, we should, as an Agile team, be revisiting and revising our own practices.
For example, it should be perfectly legitimate for a team that starts as a Scrum team to begin to recognize that maybe Scrum doesn’t fit that team or their organization very well. And they begin to learn about Kanban, and they realize Kanban actually works better for us. So at Level 12 as I became familiar with Agile development, and most of the Agile community often talks about Scrum, you will hear Scrummy things in the videos and in the conversations and in the conferences, you’ll hear a lot of people talking about Scrum. There’s a lot of things that have been adopted from Scrum, even without using Scrum things, like having a daily standup. So I was one of those people that really wanted to be a purist. So I was looking for an implementation that I could just adopt fully.
But what I realized as I began to look at implementations was that while there were some things I liked about Scrum, being a software consultant where I want to be very responsible to my client’s needs, meant that I couldn’t be really, really strict about a sprint. I might want to be strict about a sprint, but if I have a client who says, “hey, look, I’ve got this really important thing. It’s coming up in three days, I’d like you to break this sprint and focus on that instead,” I want to make them aware of the cost of doing that. But I don’t want to say no. That’s where I’m at as a business. So, I adopted a Kanban methodology as opposed to Scrum because it fit my particular needs better.
But if as we grew we had a tendency to move more towards a product focus, I should be willing as a as a business owner and leader to consider going back to Scrum, because at that point, it may serve us better than Kanban.
You should also feel free for example, if you have daily stand ups, maybe you realize the daily stand ups just aren’t working. They’re not actually helping. Nobody’s benefiting from them. Well, maybe you move to doing daily Slack reports on what you’re planning to do that day, what you did the past day, what you’re planning to do on today, and then you’re going to have a weekly hour long meeting.
Those are the kinds of changes that we’re thinking about could be something like story points. Maybe we start with story points, because that’s what everybody says we should do. But we realize that it would actually be more helpful for our team to do estimates and hours. And we’re not so concerned about our management, like really holding our feet to the fire, we just, we want to be able to plan in terms of, you know, days and weeks worth of work. And that seems more useful to us as an organization.
So we should feel free as Agile development teams to revisit and revise those practices to make sure that they’re still in line with Agile values, but they give us the flexibility to change as our organizational needs and understanding of our needs change.
I think it’s really important that the first thing the team has to ask is, do we really have the Agile values and principles at the core of what we’re doing?
Are they really in our culture? Or are we just kind of following the practices soullessly or heartlessly? And if the answer is yes, we’re just doing the practices and we’re a bit soulless, then we just need to focus a little bit more on understanding why are we doing these practices? What are the Agile principles and values that that got us to this point, let’s go back to the principles and values and then reevaluate kind of where we are in the organization and in the change process.
At that point, if we’re really confident that we’ve adopted the principles and values we should be willing to get rid of practices.
I think there’s always fear when you get rid of stuff, but we should be willing to discard practices that no longer serve the principles and values, the Agile development principles and values that we’ve believed in.
Tim Hickle:
Wow, that that really hits me hard I, in a previous life, I managed a team and we tried to use an Agile framework. We tried to use Kanban style framework with our management practices, and I had to break the structure several times for tight deadlines or things that need to be turned around. That didn’t really fit our methodology. And the feedback I got from my team is, “Tim, this feels really whiplash-y. I feel like we’re changing management structure and how we’re, how the processes we’re using to deliver things frequently.” That was unsettling to a lot of people it felt like we were whiplash and back and forth between practices.
I think what I’m realizing as I’m hearing you talk is, I didn’t do a good enough job as a leader of instilling the values. We were going through the practices, but when we had to change the practices, there is no underlying bedrock. That was, that was firm. If you if you instill those values in place, and those are firm, then the tectonic plates on top of it can shift. And it’s not going to be as jarring for the team. Is it? Am I interpreting that correctly?
Randy Syring:
Yeah, I think that’s right. Now it could have been actually that from a priority perspective you really were going back and forth a lot. I would almost have to be there to know was a problem the shifting the priorities, or was the problem that we felt like the commitment to the process was broken, in which case what you really may have needed to do is just rethink the process, right?
For example, we committed to do some CTO consulting for a client Level 12. They had two week sprints, but what I realized when I came into that organization is that they weren’t always really clear about what they wanted to work on next. The developers were getting a lot of executive whiplash. There was a lot of, “oh, we’re supposed to be economists and oh, wait, now we were supposed to be working on that.”
So there was a hesitancy like, “okay, what, let’s go two months, or let’s go two weeks in the sprint.” They were like, “oh my gosh, I don’t know that we can go two weeks.” And it’s okay, fine. Let’s go one week, you guys need to agree to let your developers focus for a week on what you said was important at the beginning of the sprint, and you can’t break that. This was more of a product shop. So this was okay. You’ve got to get in the habit of having delayed gratification on what you want to do.
At the same time, I recognize that you do have shifting priorities, and you do learn new things on a relatively quick basis because you’re more of a startup. So let’s narrow that window down a little bit so that we’re giving you the opportunity to reevaluate priorities once a week instead of once every two weeks and that ended up being a really good fit for their organization, but at Level 12 I don’t think I’d want to go that direction.
I don’t know if that’s helpful. But that’s an example of where we were able to tweak even what I did in my in my process as I applied it to a different organization with different needs.
Tim Hickle
Yeah, I love that. So I like I’m excited about this next bullet point. How do you know if a team is Agile?
Randy Syring
I think you know when the team is Agile if they know and understand the principles and the values laid out in the Agile Manifesto.
If they’re making the decisions about how they structure their process of delivery, whether that software or something else, based on those same Agile development values and principles.
When they sit down and they say, “we feel like we’re getting tossed around a lot in terms of priorities. As you begin to solve the process and put things in place to solve that that sense of being tossed about what is grounding the decisions you make?”
Is everybody’s feeling of what would work best for you going back to the Agile principles and values as written in the Agile Manifesto and asking, “how did these principles and values apply? How did they inform the decisions we’re going to make here as we’re considering how to deliver this software?”
Faux Agile is the exact opposite. The processes might be in place, they might be doing stand ups they might have a scrum master. But I’m not seeing any real commitment to Agile values or principles as they go about their daily tasks or as they go about the decision making about how to run the software development teams, or even from the higher-ups in the organization about how to think about howthe software gets written in terms of priorities – much more matching the business.
It all comes down to this: can you even articulate the values and principles in Agile Manifesto?
Again, there’s only four values 12 principles? Can you name even four or five of them? If not, if your team is not even familiar with those things, then I think it’s hard for them to say, “yeah, we’re really Agile” because they don’t really know what Agile is. They might know what some people have said Agile is, but they don’t really know what the Agile principles and values are, and, and maybe have not given enough thought to why those principles and values work.
But if they did, if they did get more familiar with them, and they did begin to learn and understand why those values and principles were chosen, then they’d be more able to apply those values and principles to the particulars of their setting.
For more information about Level 12’s development principles, check out our blog and our YouTube channel.
If you have a software project and need expert advice, contact us for a free project consultation.