Transcript

[00:00:10] Hi, and welcome to the Learnable Agile and Scrum Introduction course. In our first lesson, we’re going to look at Agile, what it is, and what it’s good for. First by way of instruction. My name is Mari Williams I’m a Director of a company called ChromeRose but in my career so far I’ve had a number of different roles.

[00:00:30] I started out as a developer and then became a Project Manager. And ended up leading large engineering teams and development teams. What originally brought me to agile was a distrust and dissatisfaction with traditional project management, which seemed to believe everything could be planned and everything could be known in advance when the reality of pretty much all software development seems to be that.

[00:00:52] We don’t always know what’s needed and what’s going to happen through the course of the project. What I like best about agile is that it accepts that things change. And helps you not kill your development team but also makes sure that you quickly and consistently deliver real value to your customers and to your users.

[00:01:12] What we’re going to cover in this course First, we will look at a bit more about what Agile is and what the principles and philosophy behind it is. We’ll then talk a little bit about Scrum. Scrum is the specific type of Agile that we’re going to talk about in this course.

[00:01:26] We’ll then look at the roles in Scrum, in the third lesson. And then, the building blocks of Scrum the different. Elements that make up during Scrum well. Well let me talk about Scrum Theatre, which sounds a bit dramatic but is actually just the, the daily meetings and the different types of interactions that we have whilst, whilst we’re in the middle of a Scrum Sprint.

[00:01:45] Then finally we’ll look at what this really looks like in the real world. Agile is both philosophy and a set of techniques. The Agile manifesto which was the original document that said what Agile was about and how we were going to go about it, notes four things that are the kind of core underlying principles of Agile.

[00:02:09] The first is that individuals and interactions. We value over processes and tools. We value working software over comprehensive documentation. We value customer collaboration over contract negotiation. And we value responding to change over following a plan. And that isn’t to say that any of the other things, documentation or contracts or plans aren’t important, just that we value.

[00:02:32] The other things first. And that they are the most important thing to get right when you’re developing software or producing websites or working in an Agile way. The same group that defined the Agile manifesto also set up some Agile principles. And these are worth having a bit of a look at.

[00:02:46] There’s 12 of them, but they’re really good as a guideline to how to approach Agile as a way of working. The first is that the highest priority is to satisfy the customer through early and continuous delivery of valuable software. And that’s a little different than some of the ways that we’ve previously worked.

[00:03:03] We haven’t always delivered things early and we haven’t always shown customers what was work in progress, what we were doing as we were going. And the second principle is that we welcome changing requirements, even late in development. Agile processes help you. Not just tolerate changes in what’s needed, but actively embrace them.

[00:03:24] I think this is the most valuable element of our job, the thing that the real game changer, versus traditional waterfall and similar ways of development. The third principle is to deliver working software frequently. Some teams do this every couple of weeks. Some even every couple of days. Sometimes every couple of months.

[00:03:44] The preference is to do that on a, on as short time scale as possible so that your users and your customers can see those changes and give you real feedback on the real product as quickly as possible. The fourth principle, something that we all know is best practice anyway, which is that business people and developers must work together but daily throughout the project.

[00:04:05] Fifth is that we build projects around motivated individuals. Everybody wants to be awesome and so we build teams that can achieve something brilliant together in a way that they organize. The sixth principle’s that we believe the most efficient and effective method of conveying information to and within a team is face to face conversation.

[00:04:27] Now, this is one that is quite difficult to do if your team is spread across different locations, different countries, or even different time zones. And we’ll talk a little later in the course about how to accommodate. That kind of situation that many of us are in. The seventh principle is that working software is the primary measure of progress.

[00:04:44] And so at every point in your Agile project, you can point at the product that is shippable, that, that works as a measure of how much you’ve done this week, this month, this sprint. Agile processes promote sustainable development is the eight principle. So, you should be able to sustain the rate of change, the rate of development, the rate of feature deployment indefinitely because it’s not a death march as some software projects have been described in the past.

[00:05:13] Continuous attention to technical excellence and good design enhances agility. This is about not letting technical debt buildup. So that at the end of a project or once you’ve launch live, you find all sorts of thing hiding under there, under the covers, under the rug that need to be fixed.

[00:05:29] And so making sure that you make time for quality all the way through the project and the product development is really important. The last three principles are about simplicity, so the art of maximizing the amount of work not done, is essential in Agile. A lot of traditional software projects and website development and similar.

[00:05:53] Gets lost because you spend so much time building all the things that you think you surely must need. Agile similar to lean, takes the approach of building the smallest thing and the simplest thing that could work. And then adding to that to meet new, new additional user needs and to scale the product up.

[00:06:13] The best architectures requirements and design, we believe emerge from self-organizing teams. And so the traditional role of a manager who kind of tells people what to do is very different in Agile. Your role as a manager, as a project manager. Which in Scrum, is called a Scrum Master, is more to create the space for the team to do their work well.

[00:06:33] And, and to achieve great things together. The last principle of Agile, which I personally think is one of the most important. Is that at regular intervals the team reflects on how they have been doing and how to become more effective. So in the same way as the product is incrementally made better at each and every time the team improves itself at each and every time.

[00:06:54] Smoothing out the ways that it works together and redirecting the processes. Don’t ever let the process of Agile overshadow the people. So what’s Agile good for and not so good for? It’s good for delivering and evolving digital product, especially when your requirements aren’t clear, mail will change. Almost all of the clients or customers that we work with, they don’t really know what they need in detail.

[00:07:18] If they did, they probably wouldn’t need us. And so, one thinks what’s beautiful about that job is that it accepts that things will change. And people will figure out a more detailed idea of what they need and what’s going to meet their needs as you go through and build the, the product that you are building, whether it be a website, a piece of software, or an app.

[00:07:37] Doing things that are new, untested, innovative, or involve exploring and experimenting are particularly well suited for Agile. And in reality, a lot of the time that’s what we’re there to do. We’re there to help people figure out new ways to do things digitally. Agile isn’t as suitable when you have products that you cannot refactor once something’s built.

[00:07:57] So for instance, if you’re building a house. You can’t really go back and move the rooms around if you decide that your design needs to change once you already laid foundations and built the walls without completely knocking them down and starting over. What’s interesting though, is that actually, when you talk to architects about their design process, a lot of the way that they design is very similar to an Agile process, right up until the point that steel starts to be put in the ground and concrete starts to be poured.

[00:08:24] The other thing that doesn’t work so well, and I’ve seen happen sometimes, is when teams where a lot of the members are working on different things try to act as if they’re an Agile team. When a lot of the point of the process in Agile are about sharing on the same product or same.

[00:08:40] Thing being built. And so, though some elements of Agile might be useful if your team is a group of individuals that are working on lots of different things, don’t assume that everything here is going to be immediately transferred.