On today’s episode we welcome back Kevin Thomas to help us as we unpack the principles of Agile! This discussion takes the form of the team going through each of the twelve principles of the Agile Manifesto and pitching in their experiences and thoughts on each. As we cycle through, the principles are weighed for their utility and thus the whole system is ultimately judged for its impact. Although there are not too many objections to the set of principles, it is still useful to look at something as popular as Agile and continually evaluate its strengths and any shortcomings it may have. This is the Agile way of looking at Agile! After discussing continuous delivery, changing requirements, frequent shipping, communication, trust and the rest of the principles the team then reflect on which of pillar stands out or has a special significance to them. So no matter your stance or experience with Agile, come with us down The Rabbit Hole as we dive in deep!
Key Points From This Episode:
Transcript for Episode 66. AGILE Principles
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:11.9] MN: Today, we’ll be talking about Agile principles and we have a guest today. Welcome back, Kevin Thomas, how’s it going Kevin?
[0:00:21.0] KT: Great, thanks for having me. So many principles, so little time.
[0:00:24.3] MN: Yeah, hopefully we’ll get through all of them and just have a nice little discussion.
[0:00:29.8] KT: There’s only 12, it’s biblical.
[0:00:34.2] DA: Are they on like clay tablets?
[0:00:36.7] KT: Somewhere.
[0:00:37.1] DA: Nice. I feel like that should be like a tchotchke where you can get for your desk. So what principles do you live by?
[0:00:48.8] KT: I have no principles, I just live my life and hope for the best.
[0:00:53.6] DA: YOLO, fair enough.
[0:00:54.2] MN: The YOLO principle.
[0:00:56.4] KT: Breaking all the rules, learning form failure.
[0:00:59.4] DA: I guess we can go through these 12 and see, maybe at least one of them, maybe kind of top.
[0:01:04.3] KT: Yeah, I think these principles are important because people do agree with the Agile manifesto, if you just do, people interactions over process and tools, if just that far, you’ve solved a lot of problems in a lot of organizations but the principles give you a way to actually like make it more concrete. They’re the more measurable.
[0:01:24.9] DA: Yeah, it’s easy to like, go to the agilemanifesto.org site and just stop after reading the first four because there’s 12 of them, that’s a long list.
[0:01:36.7] KT: Yeah.
[0:01:37.1] DA: Four is pretty snappy.
[0:01:38.6] KT: It’s a long list, it’s kind of dense, I think it will make a good podcast.
[0:01:43.0] MN: Well, let’s do it, we can just read from the top and kind of have a discussion about them because I don’t think I remember them all by heart.
[0:01:51.7] KT: All right, the first principle is, our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
[0:01:57.8] WJ: Amen.
[0:01:58.8] DA: Yeah.
[0:01:59.2] MN: Super facts, that is the truth.
[0:02:01.5] KT: Why does that help?
[0:02:03.1] MN: I mean, I think that like we need to make sure the customer’s happy with the product that we’re building and I think that that is the most important, it’s almost like why you’re hired in the first place.
[0:02:11.6] DA: Well, I think it’s important because like, when you deliver the software, they’re probably not going to be happy. You kind of like deliver earlier so that you can check with them and then adjust where you’re going.
[0:02:23.0] KT: The Agile thing there is they’ll be unhappy either way so it’s better just to find out what they’re unhappy about and then you can be more flexible, writing software from day one is the way to actually get more done and learn the most.
[0:02:33.8] WJ: Fail fast.
[0:02:34.5] MN: Right.
[0:02:35.1] DA Yeah. The phrase ‘continuous deliveries’ on their which I guess that time wasn’t a big fad like it is now or not a fad but like, you know, now it’s a buzz word that you see a lot with like CI, CD.
[0:02:50.1] KTI think the tooling at the time barely existed but it’s actually a lot easier now. Yeah, continuous delivery was like a Hewlett Packard laptop or not even laptop but desktop in the corner of the room.
But it’ll still write back then, those back then like there’s this massive C++ projects where we’re trying to like, deliver every four months instead of every nine months. Like, the whole world has gotten better and it’s partially because of these principles.
[0:03:12.4] DA: Living the dream.
[0:03:14.1] KT: The second Agile principle is, welcome changing requirements even late in development. Agile processes harness change for the customer’s competitive advantage.
[0:03:21.8] WJ: Yeah, I think it’s really easy to get scared of rapidly changing requirements because it’s really frustrating when you’re building a thing and then you discover part way through that you need to build something different but it is much better than continuing down the wrong path and shipping the thing that the customer doesn’t want after you have the information. I guess it’s better to get the information sooner.
[0:03:43.6] KT: Building the right thing actually involves having the courage to change your mind and it also means that with Agile, you come from the start, you can build things that are simple and can be changed like design to be changeable and like design to be changeable and extensible.
This one speaks to delivering business value because being first to market, to come out there a lot, like getting in front of people actually proves the value.
[0:04:04.9] DA: Yeah, and I guess even if you’re – you treat your requirements, you’re upfront, your big upfront requirements are sacred and you build them perfectly, if it’s not the right thing then you know, why did you spend all that time doing it? There’s no advantage in that.
[0:04:20.1] KT: You only prove that with a complete feedback loop to a actual customer. All right, principle number three is, deliver working software frequently from a couple of weeks to a couple of months with the preference for a shorter timescale.
[0:04:31.6] WJ: Man, we have just so completely destroyed that goal, I mean, you can ship multiple times a day these days.
[0:04:38.5] KT: Do you do that all to your clients?
[0:04:39.9] WJ: Not all but my current client, yeah.
[0:04:43.1] KT: I think delivering like once a week is more normal for my clients and I wish it was every day.
[0:04:46.8] MN: I’m usually on the once a week flow but every day is like the goal.
[0:04:53.4] KT: I think this also speaks to like iterations and sprints which tend to be one to two weeks at our clients, it also like, matters that you get those little feedback loops.
[0:05:01.1] DA: I think it’s interesting how wide of a range this is really. It’s a couple of weeks to a couple of months, it’s pretty broad.
[0:05:07.4] KT: Some projects are hard Dave, people do real programming out there.
[0:05:13.7] DA: Yeah, that’s true. I mean, some people need to land rocket ships and whatnot.
[0:05:18.1] MN: Yeah.
[0:05:18.9] KT: All right, the fourth principle is, business people and developers must work together daily throughout the project.
[0:05:26.4] MN: Yeah, I think the communication between the business and the developers must continue on a day to day basis to ensure that we’re delivering the product that will satisfy the customer.
[0:05:35.6] KT: Yeah, I found out often, the limiting factor isn’t the quality of engineers, it’s the quality of the product manager or product owner and I’ve had a lot of clients who are like, people feel very important, they have like split responsibilities so they’re just hard to get a hold of.
Yeah, I’ve been on a client that just didn’t have any product people. They had some good engineers, just building things but known as stopping to think about what to build there, just building more things.
[0:05:58.2] DA: Yeah, I felt like I could be kind of unsatisfying too. I mean, people – engineers like writing code but then if it’s not in service of a greater need or you don’t have that feedback loop saying, “Yeah, this is the right thing, this is a good job,” then it can feel kind of empty.
[0:06:15.0] WJ: This is why you need Agile to come and help you fix these problems.
[0:06:17.9] KT: All right, principle number five is, build projects around motivated individuals, give them the environment and support that they need and trust them to get the job done.
[0:06:26.5] MN: Mentioned before, in the episode you were previously on, extreme programming, trust is important, get that trust.
[0:06:35.4] KT: I think that like, the most important thing for productivity is actually morale. You’re better off giving because people along leash, even if they might not do it perfectly, because if you trust them to like get it done, they’ll like, rise expectations instead of you infantilizing them where they like lower to your low expectations.
[0:06:51.6] DA: Yeah, there’s a lot going on here too, sounds like trust like you were just mentioning and also like, motivated individuals like the practice of energized work, like the people bring their best selves to the project.
You know, the project also supporting them so that they can do that work.
[0:07:10.8] KT: All right, number six. The most efficient and effective method of conveying information to and within a development team is face to face communication.
[0:07:18.8] MN: I mean, is that the case now, what do you think? What are your thoughts on like remote work? Like people who do things remotely?
[0:07:25.5] KT: I think we can really work well, it doesn’t – it makes Agile a little harder because you need even more motivation and communication, it’s even more proactive. But, if you're talking on the phone, you can still have that like meeting of the minds and you still have the subtlety that you need. Face time is still more efficient but you can get by with remote.
And I found that it’s actually way important to me is like, as a manager and like my other roles, I know that if something is difficult, I’d rather just be in person, doing it, like, have that real communication on the set of setting emails, getting confused and basically miscommunication is really bad for certain things.
[0:08:01.3] DA: Yeah, with people who are remote, I know there are some people who are really good at just being present and being available and accessible. If you’re remote and you’re like going off on a mountain top and coding and you have no reception, you can’t communicate that person then that’s a completely different experience if that person is always on a Slack call or a Skype call with someone in the room and they’re always like, contributing their ideas.
[0:08:29.1] KT: Yeah. I think this principle is saying that those skills are still necessary even if you’re at home, to be effective on a team.
All right, principle number seven is, working software is the primary measure of progress.
[0:08:38.6] MN: Yeah, it’s got to work.
[0:08:40.7] KT: Have you guys ever been on a team where you spent too much time doing documentation or working on a spec or like doing things that don’t really contribute directly to the goal?
[0:08:48.7] DA: Yeah, I mean, working on teams that do more word full process where they’re thinking about requirements upfront and after requirements design and all that, it’s really challenging and I think it’s important to like, take a moment to like, iterate on the software, why you’re building those documents if they are required so that you can validate that you're correct.
You know, building the software is the measure of the progress. It’s verifying that your assumptions are correct.
[0:09:20.3] KT: Yeah, I think you only have so much time to do more things than just making it work. I would rather spend that time like refactoring or like making it more clear directly than trying to talk about it.
I also think this speaks well to why I hate comments in the code because you could have just – like if you write test, that helps document your code, you can write self documenting code that’s really clear.
That takes a lot of effort and if you spend all your time like writing comments instead, like it gets in the way and that stuff tends to become a lie eventually.
[0:09:48.1] DA: Yeah.
[0:09:49.1] WJ: Comments are the only kind of code that can lie to you.
[0:09:53.9] DA: That’s my favorite quote about comments.
[0:09:57.8] KT: Okay, principle number eight. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
[0:10:06.0] DA: Sustainable lifestyle, you know ,what is that? We have deadlines, we have to meet them. We need tp keep going. Overtime man.
[0:10:16.6] WJ: I think that there is a value in being able to really rally if there is an emergency but those things have to be emergencies. That means the baseline has to sustain them for.
[0:10:27.5] DA: Right, yeah.
[0:10:28.8] WJ: And when people ignore that and they make too many things into emergencies, you end up with a team that cannot maintain pace indefinitely.
[0:10:40.5] KT: And I also feel like go to people every day and then say, “Why isn’t this done yet?” They’re start to feel really bad and even if you want them to get the work done, it lowers morale and browse relate the driver of productivity.
[0:10:51.7] DA: Yeah, I think there’s also other solutions you might arrive at when you are working at a more sustainable pace than being, “Oh my gosh I need to finish this right now. It doesn’t matter how I do it.” Sometimes stepping away from the problem and giving yourself some space to think and then approaching it again, you can get to a better place and do less re-work.
[0:11:13.9] WJ: Yeah, I think it hurts the true measure of progress which is the amount of working software that you are producing because you see that as people are forced to operate under pressure and they ship things with lower quality, tech debt accumulates and people start to slow down, even if you are putting more hours into coding you could actually be shipping less and less working software.
[0:11:38.6] KT: And it clearly depends on your definition of success. You can work crazy hours of way too hard and crunch to get to a deadline but then if everyone hates it by the time you get there, you won’t have that team again to do it again. You won’t be able to maintain it, you won’t be able to do the next project but that’s a sustainable pace.
Agile principle number nine, continuous attention to technological excellence and good design enhances agility.
[0:12:02.3] MN: I think when you write good software that is extensible and has good best practices. It’s easy to adapt more future features that will come down the pipeline and makes it agile when the customer wants new features.
[0:12:17.2] WJ: Yeah, it’s taking the time to refactor, making sure that your code is really high quality and well designed. That’s what makes it easy to extend it later.
[0:12:26.0] DA: Right, doing the right thing in the moment like we were talking about in the last episode that you were on.
[0:12:31.7] KT: If you are talking about the green field being like fine and easy that’s like at the beginning of our project, you have a lot of options and it’s cheap and easy to add features because the complexity cost is low. But Agile is about keeping that green field going for as long as possible.
[0:12:44.2] MN: Keeping it green, as long as possible.
[0:12:48.2] KT: Okay, principle number 10, simplicity. The art of maximizing the amount of work not done is essential.
[0:12:53.3] WJ: They say that novice developers write code, intermediate developers delete code and advanced developers find ways of avoiding writing code in the first place.
[0:13:05.2] DA: Laziness.
[0:13:06.1] WJ: That is one of the three virtues of software developers.
[0:13:09.7] KT: I think this is the one I agree with the least based on how it’s written but maybe it’s starting to stand up very well. I just like being really iterative and doing extra work so that I am doing it multiple times but deleting each version as I go so I get the simplest shortest version that’s at the end that is concise.
But I guess that means that the shorter code is easy to maintain so you are doing less work in the future.
[0:13:31.7] DA: Yeah, it sounds like an endorsement for YAGNI like you are going to need it.
[0:13:34.6] WJ: Yeah that’s how I read it.
[0:13:36.1] DA: Just don’t build that feature if you don’t need it right now or don’t build this like really extensible thing if that’s not really a core requirement of this particular module.
[0:13:48.1] WJ: Stop over-architecting and make an MVP.
[0:13:50.9] KT: Or maybe I am just weary of like maximizing work done seems to imply anticipating work you’re going to be doing and with good Agile and XP, you need to code for it today, build that supposed thing that you are sure about.
Agile principle number 11, the best architecture is requirements and designs emerge from self-organizing teams.
[0:14:10.8] DA: Kind of like an endorsement of bottom up teams like not having the man on the top telling you what the technology and what the requirement should be.
[0:14:20.7] KT: I agree with that, like good design is incremental and emergent and you could tell it’s good because the test are easy to write and the process stays fun.
[0:14:27.1] DA: Yeah, sometimes it could be even hard to shake out what the division of stories are going to be like if you have someone who is going to tell you exactly how the division of work is going to shake out then often when you are in the trenches actually doing the thing it can be more clear how the work should might be divided.
[0:14:50.9] KT: This is still part of Agile grew out of an awesome manufacturing process that people on the floor at the bottom level they have the best suggestions for how to improve the process. If you only ask their supervisors they don’t actually do the work so they don’t know enough to make it better.
All right, the final Agile principle number 12, at regular intervals the team reflects on how to become more effective then tunes and adjust their behavior accordingly. Episode number five.
[0:15:19.5] MN: Hey that memory.
[0:15:21.8] KT: It is, it is now.
[0:15:22.9] WJ: Nailed it.
[0:15:24.0] MN: Yeah, I mean it is just like the concept of continuous improvement is really, really important to ensure that you don’t repeat bad practices.
[0:15:33.1] WJ: It’s Kanzen, speaking of lean manufacturing.
[0:15:37.7] KT: Our main tool is retrospectives like team why - discussing what went well, what went badly, what experiments do we try to improve but I think it is really important also to do the direct feedback like that face to face communication. When I am on smaller teams I like to do round robin feedback where every two weeks or so, every team member talks to every team member and tells them how they’re doing and what they could do better.
[0:15:58.9] DA: Yeah, I like that and I guess if there’s nothing really barring you from even reflecting by yourself and thinking about this at a regular interval without the team as a whole. Like you should just be keeping that as a core principle that you’re thinking about continuously but definitely doing it as a team as well or as a group.
[0:16:20.4] MN: We did it, yay! All 12 at one piece!
Yeah, I think these all practices I felt like all of them definitely resonates to me what makes a good team or a good well balanced team to get work done for the customers and to ensure that we deliver an awesome product at the end of the day. Just like constantly I think the one that resonated with me the most is probably the best architectures are made - or decisions I have made from self-organizing teams.
Because when you have that one person who knows everything and decides the tech stack then other people aren’t able to share their opinions and I think that it is really cool when everyone comes to an agreement or come with their fair share of ideas.
And it’s just like you know being at an environment where you enjoy working with other individuals and having respect and communicating properly when things go down, these 12 Agile principles definitely cover all of that which is awesome.
[0:17:22.4] KT: Yeah, I think that works because when each team member feels empowered the team produces better results. For me the best ideas out of these principles are that you need to get that customer feedback to actually provide business value and validate everything as you go and sustainable pace is really important like you need to keep morale up. You need to treat people like human beings.
[0:17:41.1] MN: Yeah, I think that is important too.
[0:17:43.8] WJ: And I think that shipping sooner helps with that. I think morale is boosted when people see real customers using their work.
[0:17:49.8] MN: Awesome, Kevin thank you so much for joining us here at The Rabbit Hole.
[0:17:54.5] KT: It was a pleasure.
[0:17:56.1] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going.
Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcasts.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
