Learn Agile and Scrum in Two Hours

Speaker A: Hi and welcome to the Agile in Action podcast. I am Bill Raymond and I am joined by Luke Pevec. Luke, before I even fully introduce you, guess what I learned in two hours.

Speaker B: What did you learn in two hours?

Speaker A: I learned Agile and Scrum in two hours.

Speaker B: Oh, brilliant. I'm glad to hear that because that's what it says on the label of the book. And if it works, it works. Awesome.

Speaker A: Great. And that of course gives us a little hint as to what we're talking about today. Luke, you are the author of Learn Agile and Scrum in Two Hours, the ultimate Agile 1, 101 book for beginners. And I really did just read it two hours in advance. You sent me this copy and it's a simple read, but it's a very important read. So before we get started, do you want to share a little bit about yourself and what drove you to write the book?

Speaker B: Yeah, of course. Thanks for the great introduction. Hi everyone. Basically this book has been on my mind for a number of years. I've written it in different variations of different guises, but I managed to meet a very talented author and publisher, Kieran Morgan, in Sydney in Australia and he co wrote this book with me. What brought with him was an educational component on um, development and education. Kieran is very talented project manager and he engaged with me on LinkedIn, like everything else in this world at the moment. And he came up with a few ideas and we settled for this one because there was a gap in the market with regards to agility, knowledge and there's a lot to read upon it, but nothing that's quite tangible in a, uh, you know, key takeaway setting that is concise and pithy. And you could kind of imagine someone starting out as a SCRUM master and carrying around a handbook. That's what we kind of thought might be very useful as a reference as well as, you know, a go to book and certain situations that you might want to reference along the way. Sometimes you might go back to the principles and values, but you kind of got to have that structure to uh, you know, go to the next level. And that is about bottom up leadership, that's about when the plan goes awry. You kind of need some instinctive behaviors and values to follow when the plan gets blown out of the water. So we thought this was important. Um, it was actually about going back from scratch and looking at who our audience was and what they really needed to know and what are the key takeaways they need to know in a summary, if they're scanning the book, so you can read it cover to cover, but you can also look at it later and reference it, which I think is a real magic piece of that book. And I'm glad to be part of it.

Speaker A: When I was in my project management days and Agile started to become very popular, I was in software development. But I was always of this mindset that you have to build this big scope statement that defines the entirety of the project, and no software developer should touch any code until we've fully defined the scope and the timeline and the human capital that's required in order to actually develop the project. And I was very much on that bandwagon. And I remember what the Agile Manifesto for Software Developers, I think, is the actual title. It's just one page, it's just a few things, and it just felt wrong to me. I remembered I was on a software development project and my team was saying, you know, Bill, that's not how we should be doing things. You should get us started immediately. Just as you're having these meetings defining the scope statements, we should be here developing things for the customer to look at first. And that's unfortunately not something I caught onto immediately. And the problem with doing that, especially since I'm a consultant, is that I already set up the contract. That way the client knew how much I'm going to charge for those first three months and how much I'm going to charge for the next three or six months when the software developers come on and they budget for that, and they budget for that quarterly. And so, by way of not enabling an agile working environment, I basically kept myself out of giving my customers some value really early and up front. And I think the problem there was that I read the manifesto and I said, this looks a little, uh. I don't know what the right word is. Pithy. It's too simple. And I didn't take it to heart. I will say it just brings back some of the most important things that you need to learn when you're getting into Agile or Scrum, and we're going to talk about that in a little bit. It just reminds you how important it is to remain flexible, especially when you're doing software development projects. I'm curious, have you experienced enough of that to have written the book? Is that what was one of your driving factors?

Speaker B: Yeah, it was a driving factor. Uh, we do differentiate in the book with regards to comparing the agile iterative process with traditional project management, which many call waterfalls because of the way each stage goes. And I think the explanation of Scrum, which is one of the successful frameworks in agility, which I deem as an umbrella term for people to. Based on the principles of people getting together, breaking the work down and solving the work together, people doing the work estimate and plan as they go through and work with the stakeholders each and every way. That kind of makes sense to me. Um, it's not to say that there's no place for traditional project management techniques and methodologies because that's simply not the case. It's very fundamental and it's very important. However, getting complex projects sold and volatile, uncertain and chaotic environments can be very challenging. So how do you do that? You need to do it in a different way. You need to do it as a team. There's no smartest person in the room. You've kind of got to work together to break information down and work through it. As, uh, a Agile Project manager and Scrum master In the past 10 years of my career, I found that really effective and it kind of gels with me the fat that you can get some outcomes and results in a shorter amount of time and get that certainty as you go through and as the project goes through and you get more successful, you're building along the way that just gives you, the team just changes. They uh, become more self reliant, they become more outcome focused on short term goals, reaching towards that ultimate goal of getting projects completed. That's a real transformation for teams in a positive way to get everyone on board and become incense like a sports team working together to succeed and win each along the way. So how do you eat an elephant? One bite at a time. It's the same thing with projects. This book I think has been enjoyable writing because you kind of go, you got to go back to the basics, you're going to get back to the values and think about the scenarios that you do every day that you might take for granted if you're working in an environment that, oh yeah, it's been really successful. I remember what it was like before and it didn't really gel for me. And working through that and actually expressing that to your audience specifically in a structured way is kind of like an agile project. But it provided that realization how valuable and rewarding agility can be.

Speaker A: I started this Agile in action podcast in 2020 primarily because of the pandemic. I saw that a lot of software developers, product teams and essentially any team in an organization, they were doing things the normal way that they always did them. And then the pandemic just sort of threw everything into this whirlwind we were changing things left and right. Organizations were changing their processes very quickly. And so I had recognized that it's really important to get the word out as to what agile is. But the whole idea, like you said, is to get small pieces of work done very quickly and then move on to the next one. And I knew that this was going to be super important. So it's 2025 now, the podcast is still going. I'm super curious, are you finding that people still need to learn the basics or uh, is it already there?

Speaker B: I think that's a really good question because I think it's a bit of a mix to that. There's no need to know, uh, answer to that. In my experience there's a lot of people who kind of get agility now and it's just part of the foundations of what people do, especially in digital and software development. Sometimes it's taught at universities or people learn it on the job and they might go to the second or third job and agility is happening. However, there's still people out there that may have been working and got a new job or working in an old environment that transformate, transitioning into it. So there is a bit of a mix. But what's important is it's not just necessarily the agile umbrella and the framework of it or learning Scrum, but it's actually about the Agile mindset and that is thinking with your term, getting those servant leadership principles in there, putting others first before yourself, ensuring that everyone understands what they're doing and then having courage, uh, and confidence to work as a team and speak up and work through a problem by working through it together and breaking it down. What do we need to do to get to the endpoint, how do we get there? And that's doing user stories and epics and tasks are all about. One good example during COVID was I was working for uh, a government healthcare software company who had 30 developers and when the pandemic hit we all basically had to no longer come into work and work remotely. That was a real challenge. We're working with health records and important data and it was extremely challenging the fact that we basically, we were all sitting at ah, our desks like we are now talking online. So as Scrum master they were all relying on me to come up with subtle solutions. I went back to my Agile practices, the Agile principles. So I had to think about ideas about working remotely and how 30 people can get into that. So I decided instead of having leadership take over, we went from a uh, bottom up position Where I had to go in and check in with everybody every day, have a, have a welfare check, make sure everyone's comfortable, and then go through and see what everyone's working on using the information radiators. In this case, we use Jira and we put it online and we shared it in the team and I had to work with them daily to get through that. But it was amazing how much we got through in a short amount of time. But we kept it consistent. We kept the framework there as guardrails, not as a, uh, formal process, but we just had to make sure this is the work we're up to. Everyone okay, what are you planning on doing next? We managed to capture the key points from that and then play it back. And we met twice a day. We went through that for several weeks because we were working remotely. And the rewarding thing was that we reached our goals, we did do our work, but we did it in a different environment. So much so that the managers above the group recognized that the process that we applied was really, really good. And we all got kudos for it. And that was really beneficial for me because the team proved that they were high performing. And then when we got back into the office and started doing regular work, that skill set stayed there and people started having the confidence to speak up a lot more. So we proved a couple of things. Number one, we, we banded together in a time of need that was unfamiliar and chaotic. We succeeded through some basic principles and repeated that and just kept to it. So we created our own environment, our own normality during a chaotic time. And when things settled down and got back into a normal routine, they became more self sufficient, more of that agile mindset, and they become more confident in doing it. That just proved to me that not just agility, but having a, uh, growth mindset is really important and you can do that together as a team. And yeah, it's really enjoyable. And I did like talking about that in the book and it gave me joy, as you can tell, going for it. It's a really good example and I think sometimes, you know, life's lessons can be a positive.

Speaker A: One of the things that you mentioned was that you stayed in this sort of agile state, but you also focused on the framework independent of necessarily what the tool might have tried to make you conform to. Can you talk a little bit about that framework? The term Scrum may not be familiar to everyone. I know we have a number of podcasts here about that, but what makes Scrum unique, and maybe you could compare that to some of the other frameworks that people might hear about.

Speaker B: Yeah, of course, indicated in the book. Scrum is probably one of the most popular frameworks around. The beauty of it is that it's, you know, it's principle based, but it is predictive in the fact that there's normal routines. Each Scrum event, for example, the planning is outcome focused. You make a plan, you've got a sprint backlog that you grab work from, and then the team choose that work based on the priority from the product owner. And the team can commit to a, uh, time box period, say two weeks, which is typical. Could be two to four weeks in a Scrum sprint. And they can do that work and they work through it throughout that two weeks to make sure that they reach an agreed goal for that sprint. The beauty of that is the planning is outcome focused. What's our goal for the sprint? And each day they have a daily standup. A team will meet at a regular time for 15 minutes and make a plan for the next 24 hours.

Speaker A: So even though you hear the words planning and scheduling and things like that, it's all within a short two week period.

Speaker B: Correct. It's iterations of two weeks. It's a bit like the Denning cycle plan. Do check, act. Scrum's a good opportunity for you to do that. The beauty about Scrum too is that based on a scientific method called empiricism, which is you inspect and adapt the work along the way so you can change to anything that might impact that. And you can only forecast on the work that you're doing based on the work that you've done in the past. So that's a great thing about agility. It provides some Scrum events that are, uh, outcome focused, that have a certain point to get to your sprint goal. And then you could rinse and repeat that and reflect on what you've done in a retrospective and then make it better into the next sprint. And that's why it's predictive cycle. And over time you improve. The example I provided during COVID it wasn't perfect, but we had some guardrails. We brought in some Scrum events, like daily standups. We had welfare checks too, just to show that everyone's okay. And that was part of it. So it wasn't just necessarily Scrum. It's an effective tool. If you know it well, you can use it. It's a guardrail that you can apply. But sometimes events in life don't let you do that, but you can use some techniques from it. Uh, it's a tool belt. Having daily standups is really good. Having the opportunity to reflect on the work that you've done as a team as a positive, whether it's in the Scrum framework or another hybrid version of it. I don't think as matters as much as the Agile mindset and the principles that you drive with it. And that is about working things together, breaking things down and solving things as a team and bringing your customers and your stakeholders along the way with you.

Speaker A: Yeah, it's really cool when it all comes together, isn't it?

Speaker B: Oh, absolutely. And there are times that sometimes things don't work, but there tends to be. A lot of people blame the process as opposed to possible challenges. Like maybe we were committing to too much work, maybe we were, uh, we didn't have enough budget. Maybe there's people in the team that aren't really embracing agility. Maybe they're being difficult, maybe they don't particularly like someone. Agility is there to make the challenges visible so that you can see them and plan as a team on how to get around them or make it better for everyone.

Speaker A: We all get started on using a, um, method, a framework, a methodology, whatever it is that you want to call it, and we just go through the motions in a very professional way and we figure out what's working and what doesn't work and we fine tune it to our own way, our own style of working. But it's possible for teams to start to lose their way. I'm just kind of curious, are there any signs where you need to step back and say, we need to refocus here?

Speaker B: Being a Scrum master for many years, sometimes you might get a key person, whether it's the product owner or some uh, of the development team. Various stakeholders might not be turning up to these Sprint reviews. They've got to turn up because that's where the opportunity, that stakeholder can look at the demo or the piece of work that's been done and provide some feedback on it. That opportunity is so powerful because it removes all the other ad hoc meetings that you can free your day up with. The development team is there to show you the piece of work that is done and that you can provide that feedback and then they can take it back and play through it. The fact that the Scrum framework and actually other Agile meetings and Scrum events are there specifically for an outcome focus and the opportunity to reflect as a team, to improve your skills and get on with it is so important. So I think there's a bit of a balance Here between the Scrum master to try and champion the value of scrum and the value of agility. But it's also up to the rest of the team. But once the team has gelled together and they've gone through the forming, storming, norming process, they will instinctively understand that and then the proofs in the pudding with the team getting in there. But yes, there is a challenge with the buy in but that challenges doesn't matter what framework it is. So that's why I think it's quite important, especially at this day and age where some people are remote, some people are working together as a team, uh, is about the agile mindset over uh, frameworks, over processes. What's more important is you as a person and how you treat others and you work with your team together to get the best outcomes. Not just for work, but also for your personal relationships as well.

Speaker A: I love that. I think that's such a great way of wording it. People ask me what is the Agile in Action podcast? Every now and again they're saying, well uh, you know what, uh, we've tried agile or we've tried project management, this style of project management. And it's interesting I tell people that it's an opportunity that to organize your teams so they can be successful and have it be a psychologically safe environment. And when they have that they perform.

Speaker B: Oh absolutely. I think it's quite fundamental that people are, you know, even if you're just curious, this book can help you give you that enough information to take the next steps. And um, it's really comprehensive and as you go through it it will show you the value and it's not just the process, it is the outcomes and how working together as a team can achieve a lot of positive and successful happiness and outcome to rule.

Speaker A: Absolutely. I'd like to ask you about the elephant in the room. Every software developer is expected to suddenly be an AI expert. There's this call sometimes that you might see especially on social media platforms like LinkedIn. There's this call for agile is dead, Agile's broken. What's your response to that?

Speaker B: There is no black and white solution or answer to this. I follow a lot of what you say about that and it's just embrace new technology, don't be afraid of it, get to know it and let it become your friend. I think from what I understand there is still demand for incredibly talented people who uh, can be problem solvers and be solutions. It's about embracing AI and seeing what it can do. From what I understand it can avoid some of those repetitive tasks like scheduling and probably giving you a better version of a user, uh, story that you might be writing. You can kick the tires by using AI to help you sense check that and provide that. What am I missing from here? I always find it with AI for a lot of my writing, doing preparation work and research is like, you know, I'll have some notes and I'll just want to structure it. What else does my buddy copilot in this instance that I use or chatgpt? What am I missing from this? What am I? What do you think I'm doing this? But as people working together and problem solving, AI is just a tool there to help you enhance what your team can do. It's just there to, um, guide your initial thoughts and maybe help curate them in a way that can get you to where you want to go a little bit faster. I, uh, think having that mindset, just treating it as a tool, but also as a friend to sense check things, is a reasonable and sensible way to approach it. At this stage.

Speaker A: This framework for stepping back and everyone on the team working to define what exactly you're trying to accomplish, what are the outcomes, what is the value. That's super important. Maybe a sprint is no longer two weeks, maybe it's a few days, who knows, because of all the automation you can put in place. But I do think that there's still something to be said for getting the team together on these things because a lot of these AI products allow software developers to code super fast and we won't get into whether it's good code or bad code or anything like that. It can speed up the software development process pretty significantly. And I think one of the things that this framework helps with is to remind yourself, just because I can code it and I can code it quickly, should I and should we as a team and does this make sense to our customers?

Speaker B: Yeah, absolutely. The great thing about agility is, you know, whether it's the development team, the scrum team or the project team working on it, it's about doing it together, problem solving and breaking that information down. If you're using AI to help you do that, it should be done within reason, within your control, and then it helps you as an aid and guide to get there. But the fundamental thing is by doing as obtained, you've got buy in and people are encouraged to stay focused and engaged and are motivated because they've got a seat at the table, they've got a say and they can work through it together. So there Is that balance? Like I was saying before, but agility should never be leading any conversations, especially in Vuca environments. You know, volatile, uncertain, chaotic. It can be there as an aid, but that's what it's for. And, uh, it's a great friend to help you with. But like I said, you're doing the work. You're empowered to do it and lead, and that's what I love about it. In the near future, I think there'll be time for it to settle down and it'll be a new norm. But I do believe it will involve people doing the work, because that's where the value is.

Speaker A: I really appreciate that thought. Thank you very much. I have one last question for you. We've talked about agile, we've talked about Scrum, we've talked a little bit about how AI might be changing things, but still we have these ideas of keeping the team focused on delivering value. What is something someone could just take away from this podcast and do right now? To use some of these ideas and methods that you have documented in your

Speaker B: book, I think for me, you can learn about the basics of agility, which is really great. But I think taking away from this book is about focusing on the agile mindset. So when you're working with your team, how can we better collaborate? How can we improve our feedback loops to make them shorter and faster? And how can we continuously improve the power of reflecting it as a group and capturing that information and bring it into your next iteration is highly important. The key information about working together to get something done is about doing it together and reflecting on it and speaking with each other and working as a team every day. You can't help but build trust. And if it's not there, people as a team, you'll need to do something about it. So it's great to have an environment where you iron out the kinks and sometimes if there's conflict, as long as it's healthy conflict, that conflict ideas as opposed to personality. It's really powerful and I think that book will provide you some really good tools to take away with you for that journey.

Speaker A: Luke, this has been a great conversation. You've actually been on the podcast before. You talked about career progression. You're also the author of an Agile playbook for technical communicators. And this new book that you just released, Learn Agile and Scrum in two Hours is a great book. I appreciate you sending it to me. It was a super easy read and it just reminded me of some of those basic principles that I need to go back to Luke Pivack. If anyone wants to reach you, how might they do?

Speaker B: So please feel free to look me up on LinkedIn. It's Luke Pivac. P I V A C. And I'll be there. Say hi and yeah, got any questions, let me know.

Speaker A: Thank you so much for your time today. I really appreciate the conversation.

Speaker B: Thank you.