Being Agile - Taking your first steps

1. Trailer: Theo world of work is constantly changing. Everyone is under pressure to be as productive as possible to doom or in less time, we push and push ourselves. But it could be hard to get the results you want. More importantly, it can leave you feeling burnt out. Hi there. I'm downward would. I am an agile coach, a consultant. I know what you're going through. I've spent 10 years following my passion to understand how teams, people and organizations work. I've helped hundreds of people to be more productive on, more importantly, to be happier at work. As a result, you may have heard the badge always working is quite popular now, especially in the world off software on digital. But its ideas can be used in pretty much any kind of work. I often find the agile weight of working a misunderstood, which leads to people not understanding how to make the most of them. I was inspired to make this course to give people the training I didn't get right at the start. It's perfect. If you're completely new to the subject on should be really interesting for those you've taken a few steps already. Key concept I want you to take away from this court is that doing agile isn't a thing. By the end of this course, you'll understand what it means to be a joke and how you can start to work in better ways. In this course, we're not going into depth around any particular methodologies or frameworks. Instead, we're going to focus on the core heart of adult. We're going to cover the history and ideas of that job, the Anjan mindset, the agile values, agile principles on making changes at work. If you're inspired to take this class, then let's start as we mean to go on. My object is a maximize what you learn throughout this course on. That means I need your participation. So before you start this class, I want you to become prepared and get those sign ups is firing? Write down five things that you know about agile already. Don't worry about looking stuff up. I just want you on his thoughts down on paper. The second thing, what is one question that you want to answer by the end of this course, write it down so that we can compare notes later on. Lastly, what do you plan to do with the things that you know? Being a jar means continuous improvement. So have a think about how you might apply your new skills at work. I'm really looking forward to teaching you. I can't wait to sign up. 2. Introduction: Hi that Thanks for taking the course. I really hope you enjoy it before we get started. I just wanted to take a few moments to help you get the most out of taking the course. If you haven't done so already, please go and download the workbook. It's designed to be printed out. I hate killing trees, but we worked most effectively when we can write things down rather than just watching and listening. But if you can use recycled paper, please do. Throughout the course, there will be opportunities for you to record and test the things that we've been learning . At the end, you'll have your own personalized workbook that you can use in your own place of work. I will be something that you can come back to in the future. I'd love to see your workbook, so don't forget to photo or scan yours on. Upload it to your project. I'd also really recommend using the discussion section to talk around the concepts that will visit on your always welcome to ask me or other students questions along the way. Okay, let's get started first. An important point agile is not a method framework or process. It's actually much more simple and much more powerful than that. In 2000 and 1 17 people got together up a mountain to chat and ski. All these people had two things in common. They were frustrated with how organizations rang software projects on. They were all experimenting with ways to make it better. Okay, okay, so these guys were all from software backgrounds, and you might be thinking what software got to do with May. I promise this is still relevant to you on will be discussing later how these ideas can be used in any kind of work. You see, most projects didn't go very well. They sometimes spent months gathering requirements and then took even longer to make things . Then, of course, people want to changes, which meant suffocating change control. So the projects often ended up over budget. Andi over time, that's if they were ever lucky enough to release anything at all. The people at the ski lodge had experimented with other ways of working. Quite surprisingly, they found that their approach is actually shared a lot in common, so they distilled their view of how to approach the work into what is now called the Agile Manifesto. We're uncovering better ways of developing software by doing it on helping others do it. Through this work, we have come to value individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration over contract negotiation, on responding to change over following a plan, that is, while there is value in the items on the right, we value the items on the left more. The manifesto also has 12 guiding principles, which will be visiting in future lessons. Basically, agile is about how you tackle complex problems, which means it's not a recipe you can follow. Think of it this way. You don't try toe do health every day. You can try to be a bit healthier. That's really allow agile is It's a guide to being a bit more agile. Being more agile helps us deliver amazing products and services to our customers. So how to all of those frameworks and methodologies fit into this? Think about agile like a big umbrella. Underneath it are a load of different methods, frameworks and techniques. They all try to live up to the agile values and principles in their own way at its heart agile is common sense working, and it has applications outside of just making software. Okay, so that's the agile manifesto. The people who wrote it actually put it up on the Web, and you can even sign your name in agreement of the values I could have linked to the manifesto below, so you can see it for yourself. Here comes the workbook, because the manifest that was created in 2001 page looks a little bit dated. To put it nicely. Your first exercise is to create your own version of the manifesto in your workbook on Complete the Small Quits When you finished, I'll see for the next lesson. 3. The Agile Mindset: So in our last lesson, you were introduced to the agile manifesto. How did the exercise go? Don't forget. Upload your work to the project section to share it in this lesson, we're going to cover what I call the John mindset. Whilst there are many methodologies, practices and frameworks that you can follow, you're probably not get the most out of them if you approach them from the wrong perspective. A good deal of what makes being an job powerful is that it's a way off approaching and thinking about all aspects of your work. The reason I put this lesson in is because that's the biggest hurdle that a lot of people face. All too often, people follow a process they've read. But unless they understand why they're doing things, they can't learn when things go a bit wrong or when they need to take a different approach when we want to change the way we work. What we're really talking about is changing our behaviors. The way we behave comes from a set of values that we hold deep inside of us. Those values influence our decisions, perspectives on interactions. Our values are also key in building and keeping trust. When I was early on, in my agile journey, I was working with the manager. He'd read the same content as me so we could talk. A pretty good game on would often impress others with his knowledge. One of the things we often encourage in agile ways of working is making stuff visible so people can see it on. Do something about it. You could say that we value transparency. However, when it came to a world that this manager had been asked to do, he protectively guarded everything. So he was the only one with the information. It was his tactic to try and make himself indispensable. His behavior was a contradiction to the value he espoused. People quickly see past that unauthentic city, and it erodes the trust that you need to make valuable changes. So values have the biggest impact on making changes to our behaviors, but they're also the most hidden on inaccessible parts of our personality. You can't just turn around to someone and say value collaboration because our values are built up over a long time on a great deal of experiences. Values are intangible and hard to change and in business, we often avoid the things that are hard. The place where people usually start is with practices, tools, processes, a method of how to do things. Practices could be really attractive. They're accessible, relatively easy to learn and could be changed immediately. I wonder if you've got any experiences off a process being adopted at work with promises that they'll fix everything, Did it? That kind of silver bullet thinking is often why people who are trying the process is under the John umbrella. Don't succeed as much as they'd like. They're following the rules, but they don't know or sometimes even care about why those rules exist. The good news is that is a middle ground. Principles exist that add context to values, the less accessible than practices on required time and discipline to adopt. But they're also a guide to how we can live the values that we want to adopt. I often think that Mazar, if in doubt, do this. Guide practices won't cover every scenario, and sometimes they won't be right for your particular set up or conditions. Principles are there for you to go back to basics and asked if we can't do that particular practice, what could we do that would live up to the same Angela principle? And would it represent the agile values? So we've just explored the agile mindset. I'm not saying your practice is far from it. They are an essential part of being a job. But try to understand why those practices happened. Which principles do they follow? What value are you being an example off? When you're behaving that way, it's thinking, Think time. I want you to reflect on what you've learned in this lesson and then go back to your workbook in the mindset section, I want you to do a few things, go and find the values of the company that you work for and then recalled them in your workbook. If you're a freelancer than think about your own professional values, then write a short list of 3 to 5 of them in the workbook. Next, write down how your current processes Ways is working on approaches, demonstrates your company values next, right down 1 to 2 sentences on how you think a set of principles can help you guide you on your journey. Goto that, if not just come back and refresh your memory later. Now, before you start the next session, I need you to make sure that you take a break. Don't have a walk around, stretch. Have a drink. Whatever works for you to keep the blood pumping around your and getting that juicy oxygen to your brain. I'll see you again in 5 to 10 minutes. 4. The Agile Values: So how is that exercise? Do you feel refreshed after your break? You did take a break, right? If no, don't worry, I won't tell anyone. Go and take a break now and I'll wait right here. So let's move things along. Now you're getting into the agile mind set. Let's focus on the four core values that set of the heart of the agile manifesto. The first value is individuals and interactions over processes and tools. I feel that this one is particularly important to start with. It puts humans at the center of effective work. I find it ironic that now I just become a bit more mainstream and commercially acceptable. A lot of focus in the agile community seems to be around selling processes and tools unless on the individuals and interactions off the community. In the absence of a process or in the midst of a bad process, you can still be Angela. If you remember this value, think about how you interact with others. What are the key conversations that need to happen to make the work move and how can you build report with colleagues, clients and stakeholders? The second value is working software over comprehensive documentation. Okay, so we've hit our first bit where software is called out specifically. But let's go a bit deeper into the meaning of this value. Why do you think that those people valued working software over documentation? This value is all about acknowledging that getting the work completed to a high level of quality is more important than trying to have a lot of bells and whistles. It also emphasizes that we do our work in the service of others, and that's satisfying. Our purpose is more important than satisfying the needs of a process. Off course documentation is needed, but it should be just enough to support our efforts to deliver to our customers. That's value Number three. We have customer collaboration over contract negotiation. Often, work is seen as having winners and losers. That's a business we seem to set out to be defensive in our relationships. We should instead focus on creating mutual value for everyone involved us. Our customers supply chain anyone I working with each other, we all win. Don't let defensive paperwork and be ocracy. Get in the way of you working in the service of your customer when you act in partnership and build good relationships, you'll make better products and services. It's certainly not an excuse to not have contracts to safeguard the relationships, but try and Orientale contracts to support collaboration rather than confrontation. Lastly, for this lesson is value for responding to change over following a plan when the things we need to make a well understood and repeatable plans are a fantastic way of ensuring that what we need to do gets done in the right way. The problem is, the type of work that we have to do is not the same type of work as construction or manufacturing. We don't have the luxury of knowing what to build on Dwyer not always sure of the best way to build it. On top of that, the lay of the land is constantly shifting, meaning our assumptions can change from day to day. And that kind of environment is not a plan that will see you to your destination. It's actually lots of plans that are constantly being updated. Instead of fighting, change with expensive and slow change management gates Embrace the change. Use it as a catalyst for learning. Focus on responding to what you learn so you can exploit your insights. This value is not about pandering to a client's need to change things along the time. It's about trying to learn as quickly as possible so that you can change your direction with your customer and create a better outcome. As a result, as Eisenhower aptly put it, plans are worthless. But planning is everything. Don't forget to visit your workbook for the next exercise, and I'll see you for the next lesson. 5. The Agile Principles - Part 1: Do you remember the start of this course? We talked about the Ajumma professor having 12 principles. The next three lessons are designed to take you through all 12 principles. Remember, our John mindset tells us that principles are the best option to changing our behaviors in a way that lives up to the edge. Our values, the principles are going to be are sign posts on the way to being and job. Now, some of the principles are very software orientated. When that happens, we'll focus a little bit more so that we can delve deeper into how those principles could be applied to other types of work. Let's get going. The first principle, our highest priority is to satisfy the customer through early and continuous delivery of software. If you remove the valuable software paths principle and replace it with just value on this principle is a great place to start off. I really like the part that mentions early and continuous delivery. It qualifies the difference between delivering your value at the end or continuously. As you build a relationship with your customer. We want to emphasize delivering some value as quick as we can on then reliably repeating that level of service as we go at number two, we have welcomed changing requirements even later on in development. Agile processes, harness change for the customs, competitive advantage. Remember our values. This gives us a concrete principle to follow that allows us to respond to change and to look at that change in a positive way. Change is a way for us not to just respond quickly to our customer, but it's also an opportunity for us to use what we've learned for the benefit of our customer. The third principle is deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale. Okay, first, let's have a look about software bit in that principle. What do they mean by working software? In fact, the software part is almost irrelevant. Well, we should focus on is the working part. It's not good enough to just deliver quickly. The emphasis is on delivery at a high level of quality. Even if we deliver quickly and often it still needs to be at a level of quality that meets the expectations of our customers, hopefully even delighting them. We want to deliver that value in the shortest time scale possible onto principle Number four business people on developers must work together daily throughout the project. Remember collaboration over contract negotiation. Sometimes our customers are not the end customer. Sometimes they're within our own organization. This principle is a great example of how to break down silos towards a common purpose. Let's just change developers for team members. By working together daily, everyone can stay aligned and focused on achieving the best outcome possible. It helps to stop gaps in information on also creates tight feedback loops. This is a fantastic way to learn quickly so that you can respond to new insights together. Okay, that's the 1st 4 principles covered. We'll cover more in the next two lessons. Check out your workbook as there is an exercise that covers the principles there. But if you're keen to get going, move onto the next lesson and completely workbook at the end of this section. 6. The Agile Principles - Part 2: welcome back to the second part of our review of the 12 agile principles in this lesson will be covering principles 5 to 8. So let's get right into it. The fifth principle was one of my favorites. Build projects around motivated individuals, give them the environment and support they need and trust them to get the job done. If only more organizations followed this guidance, it often perplexes me that we could spend literally millions hiring people into an organization and then become obsessed with controlling their every move. We denied them the things that they need to deliver value to our customers. It's so short sighted. At the heart of this principle is great management, but not great management of people. It's about great management off the system on environment that people work in. It's about creating the conditions for success. If you could do that right than excellent emerges at number six, we have the most efficient and effective method of conveying information. Two on within. A development team is face to face communication. Now this doesn't necessarily me in person, although that's usually the best scenario. What is important about this principle is that it's about a conversation. Most communication is nonverbal, so face to face communication is actually an incredibly efficient way of conveying information. It allows for the sharing of context and experience, which makes it more likely that the information is understood first time round. This means that ideally, you want to optimize your ways of working around face to face communication. Could you sit with your team? Can you move and go and speak to somebody instead of picking up the phone or writing an email? Were all these little tricks add up to improve the quality of the communication onto principle? Number seven Working software is the primary measure of success. Let's extract the software part of this very short principle of focus on the point of this principle is trying to make. How do you measure success? How your efforts judged or measured at work measurements can be really useful. They tell us if we've achieved a goal, but they could also tell us if we're on the way to achieving ago. However, all too often we fall into the trap where the plans, charts and status updates become the thing that we focus our work on. It's like we're tryingto please the sprint sheets. If the traffic like status is green, then everything is fine, is it? If you've not produced high quality value into the hands of your customers, then nothing else matters. Likewise, if you have managed to deliver value into the hands of your customers, then you should not be unfairly judged if you've missed a tick box. In a particular measure, number eight agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. This is often another principle which is blatantly ignored. Are ways of working should never assume that there's an in date. Producing high quality, valuable work to our customers is a continuous act. It makes sense, then, that our processes should be designed to support that approach. When we work in projects, however, we often don't think of it that way. We concentrate all of our efforts in pleasing the project plan and think nothing of overtime sleepless nights and moving people around it well in order to satisfy a project showing us on track that just isn't sustainable. It's also ethical to treat people that way. They're not machines. When you overstretch your team and the opposite happens, they burn out and things slow down. The long term effect, often unstable practice is that your projects are more likely to fail instead of focusing on the resource efficiency, that is, how well utilized people are and how hard they're working. Instead, focus on the flow efficiency. That means focusing on the time it takes to deliver value along the entire process. It might seem weird, but you'll actually get better throughput and short Alito's. By focusing on the flow of work, Andi people will be happier, and that's always a good thing. That was a lot to take in for this lesson. I think now is a good time for you to take another five minute break. Make sure you get up out of you, see and take some deep breaths. I'll see you back here soon for the last lesson covering the agile principles 7. The Agile Principles - Part 3: feeling refreshed from your break. Great stuff. We're covering the Final Four and job principles in this lesson. Congratulations for keeping pace so far. The ninth principle is continuous attention to technical excellence and good design enhances agility. Quite often, we feel forced to focus on speed along costs. The problem is that this often means more work in the long run. Why does that happen? You may ask, when we cut corners in quality would produce work with defects. Unsurprisingly, customers don't like defects, but they are more than happy to send them back For us to fix, that means we have to spend additional time fixing the problem when we could be working on something new. It also means that it takes longer for us to learn if the work that we did is right in the first place, extending the time it takes for us to learn enough to adapt. Good design has many aspects to it more than I can cover. In just this lesson, the part that I like to focus on is part of this principle. Is effectiveness making the right things by making sure that we learn what customers need. We can understand what problems they face and then decide how best to solve that problem. This doesn't mean lengthy, costly requirements faces good design, focuses on rapidly iterating an idea and learning from customers as quickly as possible. That way, we can then execute on the idea with ruthless efficiency and canned, then avoid unnecessary work, which leads us nicely onto principle. 10. Simplicity. The art of maximizing work that is not done is essential. Traditionally, customers get used to projects not delivering on time. To counteract this, customers will often ask for the earth and will only accept a result that includes everything. When we start to deliver value sooner, customers have an opportunity to learn with us to realize that having an endless list of requirements is as much a waste of time tow them as it is to us. The other track that we fall into is thinking that starting work doesn't have a cost. With the pressure to go fast, to be busy and to be fully utilized, we constantly commit to starting work. The problem is, the more work that is moving in progress, the slower we are in our ability to actually deliver value, we end up constantly switching between work, responding to someone who's shouting or complaining. The loudest simplicity also means starting work at the last responsible moment in order to deliver it just in time. That way, we're not overwhelmed with work we can concentrate on finishing on. Ultimately can deliver value quicker to our customers. The more work that can wait to be started, the better. So if the customer changes that mind about something that hasn't been started, then there's no cost. You can simply choose to start delivering something else instead on what you decide to start on is likely to be the better thing. Principal 11 is the best architectures requirements on designs emerge from self organizing teams. This principle should hopefully be self explanatory, however. How many times have you or your team being handed requirements produce with the structure or design was made by somebody else. Most of the work that we do is complex, and we're not machines that could be given a recipe to produce. If you want something to have the right outcome for your customer's needs, then the best people for the job are those who could organize themselves to solve the problem across silos and boundaries. Self organizing teams can get close to the customers, understand the actual problems they face and co create the solutions with them. They're also better place to understand the challenges in solving the problem and can create solutions that are not just right for the customer. They're also more maintainable and extensible by the organisation. Lastly, we have principle number 12 regular intervals. The team reflects on how to be more effective and then tunes and adjust its behavior accordingly. For me, this principles about an obligation, you and your team have an obligation to grow and get better. You can't assume that what works a day is going to work forever. No, quite, we're not perfect. We're going to make mistakes, but that's OK. As long as we learn we can make things better. It's not just about learning to make the best products and services. It's about regularly learning about yourself so that you can continuously inspect and adapt along your journey. It's the best way that I know to make sure that the journey is challenging on fun. Wow, we've made it the 12 agile principles. If you haven't done so already, make sure you finish the workbook section on principles. That way, you've always got a reference guide for the future. Next up, we'll talk about how you can start to take this knowledge and apply in your workplace. I'll see you in the next lesson. 8. Making Changes: This is the last short lesson of the course so well done, and taking in all of the information in this lesson will focus on how best to start making changes at work were making changes. Little is more big. Changes are harder to make. They're more disruptive on they encounter the most resistance. I want you to focus on learning as the primary objective of change. We want to learn as quickly as possible. So that means small little changes with little changes we can learn quickly on. If we do make a mistake, the impact is going to be small. That way we don't have any fear when fears removed were more comfortable to push ourselves outside of our comfort zones. We're not worried about Reprisal is in this space where we can learn from our experiments and come up with new, better ways of working. Small changes are also a great way of building up trust in others. They feel what you're doing isn't scary, and they start to understand it's for the benefit of your customers. It builds up confidence in others that you can be trusted to do the right thing. Please always remember that there are going to be practices that happened now that still work, respect the things that do work. People worked hard to make. The practice is the way they are and will be protective of things that are changed for no obvious reason. Just remember to take your time. Don't try and change everything at once and keep your vision visible so you always have something to aim for. With others, change can be difficult for others, especially if they don't have the same knowledge as you. So you're challenge for this lesson is to find someone, perhaps a colleague, that you work with. Tell them about the agile manifesto, its values and principles. Discuss with your colleague about possibly trying to work a bit differently in a way that lives up to those principles. See how the conversation goes, then come back and record the output of that conversation in your workbook. Did you find a successful what didn't work so well? And most importantly, what did you learn 9. Final Thoughts: So that's it. The end of this introductory course. I really hope that you enjoyed it and found the contact useful. Always remember, there's a difference in being agile than just doing. And John, you can't do a job, but you can do your best every day to be a little bit more agile in the way that you work and try and live up to the values and principles of the agile manifesto. That's what it means to be an Joe that's you'll go remember, even though there are lots of frameworks, processes methodologies out there, you have a responsibility to forge your own path. Find out what works for you in your context. For your challenges. Build your own tool box of techniques that you can apply to any situation as long as what you're doing is in spare off and upholds the values of the agile manifesto you can call yourself evangelist. I hope to produce a more lessons where we can delve into some of the frameworks a bit deeper to help you build up that toolbox as well as in techniques for great teamwork. So don't forget to follow me on skill share, so you can hear about those courses where they're ready. Thanks for being such a great student for the remains. Is one last exercise review the knowledge of agile that you noted down at the beginning of the course, Reflect. Was that knowledge correct? What's changed has the question that you asked at the start being answered. Has your action plan now changed? Lastly, I wanted to write down 3 to 52 DUIs about how you might experiment with the agile mind set . Remember to put them in your workbook so you can refer back to them. Don't forget. Share your completed workbook with other students in the project section. I wish you all the best in your Angela. Joni. Good luck.