Agile presentation notes
Download as DOCX, PDF1 like80 views
Agile is a philosophy that values individuals and interactions, working software, customer collaboration, and responding to change. It aims to deliver value to customers faster through iterative development cycles. While Agile provides benefits like faster feedback and adaptation, transitioning to Agile can be challenging for established companies due to required changes in mindset, processes, and culture. Lack of documentation under Agile also poses challenges when new teams must support software later.
Agile presentation notes
- 1. 1 What is Agile If you are talking to a Business Analyst or an IT person or a development manager or company executive, you will all get different answers. And there are a lot of anwers out there. It is little bit confusing to understand what Agile actually means. Personally to me Agile is a philosophy and a way of thinking that’s guided by four values and tweleve principles. I want to you to think about Agile as a mindset over a framework, process or methodolgy. History of Agile Looking at the history of Agile, it was coined back in 2001. 17 highly opinitiated expert software developers got together in Utah to discuss what are some of the things that they were doing in software development that was working. Some folks there were from Scrum. Some had really good experience with Lean and had been able to make lean work. Others had experience in XP. And there were some other ones that had some other form of these methodologies. That is the reason why they couldn’t really agree on one methodology or one framework on what to call Agile. However, they agreed on the four values and tweleve principles, and that is how the Agile manifesto was orginiated. Expalinging Agile to a layman If I had to explain Agile to someone who had no software development experience, here’s how I would do it. In this day and age, everybody has some exposure to using web sites or using application in their phones. So let’s just simulate a very simple example. You have X amount of dollars and you want to build an app. Let’s say this is a game that you are trying to build and you have a certain amount of money and you hire me and my team to build this game for you. How would you want to get your product delivered to you? In what fashion would you want value. In a weekly basis, or would you want us to give you a lot of documents and wireframes and different ways of doing it except the working software. Obiviously, the working software. How would you want us to work with you since you are the customer? Would you want us to collaborate with you and come up with on how you should build this game? Or would you want us to lock into a contract where we only deliver you what you gave us initially when you had only so much idea about your team? Another example, the game that you thought of you had a specific plan for this. But a month into it, let’s say there is another competitor that has already developed a really good game that has all these features. However, you get a pretty good advice from investor who wants you to tweak a few things and that makes your game still viable in the market. Would you want your software development team to be able to respond to your needs in the changing environments? Or would you want us to give you hard time about, hey, you gave up this roadmap, this plan, and we’re gonna stick to it. Obvioulsy, you want to us to be flexible. So that is what it means to agile from manifesto perspective.
- 2. 2 Now let’s look at the Agile Values. Individuals and Interaction Over Processes & Tools What do they mean to you? Individuals and interactions simply means to me that we value people, and we value interactions among people when they’re developing a software. And this can be the team level. And also, we value interacting with the business folks. It’s important for team members who are building the software to interact with stakeholders or somebody who is giving them what needs to be done. But at the same time, it is important that there are enough interactions between the team members or multiple teams that are building this piece of software. And what we are saying is, not that we don’t value processes and tools. Yes they are important but given a situation if we say we want to be Agile we are going to value the people and the interaction more. So to me, this statement means we value more face to face communication or our communication over a quick phone call versus emails and creating a ticket that takes a lot of time and creates a lot of confusion. Not to say that we cannot email or we don’t value any processes. Another thing that I can think about is estimating. Whenever it comes to estimating the work froma development teams perspective. Sometimes team members get hung up on how big this item is. And when we come to that situation we are going to value the interaction among the team members and talking through what are the complexities of this work and why do we think is so complicated. So we’re going to value the interaction more than the actual story point or how big the story is. Working Software Over Comprehensive Documentation It doesn’t mean that we don’t need to have documentation. In fact, it can be super frustrating if there is no documentation and it can be really hard for the developers or customers to kind of navigate through the software. However, a key thing that you want to pay attention to in this value, is comprehensive. Let’s not spend a lot of time just writing documents because the main deliverable is the software even when you’re thinking from capturing business requirements perspective. One of the main thing that comes out of gathering requirements is shared understanding. What this principle says is you could create this shared understanding by actually just having more conversation among the team members and with the stakeholders and potentially even the customers. In one way you can accomplish this shared understading of the software is by creating small increments of software and putting in the hands of the internal stakeholders or the customer so that you can gain feedback from them on what they exactly want out of the software. So, in conclusion, you want to create more working software. We want to learn faster and going to create a shared understanding. And yes, the documentation is important but let’s just not go all crazy about documents. Customer Collaboration Over Contract Negotiation The third value of the Agile Manifesto is customer collaboration over contract negotation. The key thing that you want to keep in mind in this value is customer collaboration. We want to collaborate with our customer because we want to delight our customer because we want them to come back to us and rely on our expertise for developing software. `
- 3. 3 However, we want to change the way we write our contacts or agreements. In the past, most of the times, most of those contracts are written based on business requirements or functional requirement documents which throughout the course of the proect, it is so hard to predict. And usually these requirements change and there goes the contract where now as a development team we have to kind of go based on the contract and the client will actually have us execute on the contract, which it’s a lose-lose situation versus what we are suggesting is have a contract in a way where we are keeping customer success in our mind. It’s actually not fair for development teams to ask for all the requirements from the customer or the client in day one. They’re coming to you in the first place for help because they want this piece of software to be built by you. So rather than putting them into a strong contract, we want to collaborate with them and help them understand what they need in the software so they can really delight their customer. So this principle is saying that instead of having a strict contract upfront, collaboration is the key. Work with the customer or the client throughout the project and you want to create a win-win situation where if your customer or your client wins then you win. Responding to Change Over Following a Plan The last value of the manifesto is responding to change over following a plan. This value just means that having a plan is very important. It’s almost silly not ot have a plan. In software development we have all kind of plannings. However, less value on being ready and being able to respond to the changes if they actually happen. Tranditionally, when we’re planning for proejcts what we are saying is if the conditions of the universe didn’t change between now and the moment, what kind of things would we do in order to accomplish this project and we write those things down and we talk about it and we document it and we can actually throw that piece of plan away because most likely if you’re developing a complex piece of software, somethig will change and then the plan will not be useful. So planning is very important. We need some kind of plan but we need to be able to respond to changes as they happen in a complex environment. Agile Principles All 12 agile principles are crucially important, but here I will discuss the top 5 according to my experience. 1. Deliver Value Faster The biggest reason Agile got created was because the traditional methodology, such as waterfall, weren’t delivering value until the end of the project. So there was a whole bunch of work, a whole bunch of effort, a whole bunch of money being put into projects upfront and the business wasn’t seeing the value until weeks, more than likely months, more than likely years later down the road. So the deliver value faster principle that we’re going to deliver that value to the business much sonner and have them realize those benefits and that value is critically important and is the reason why that is one of the first princples on my top five list. 2. Welcome Change
- 4. 4 Next comes welcome change, again with traditional methodologies the business really gets sick of hearing no. Because in the traditonal methodology you have various stages and once you get past a certain stage you can’t go back. So once you get done with the requirements, you get into design, you’re not supposed to go back and add requirements to it. Once you get into development, you can’t go back and redesign it and it just makes it very difficult for the business because the business is always evolving, right, all their needs are always changing. And so the Agile principle of welcome change is saying regardless of where you’re out in the project, if you’re at the beginning, the middle or at the end, business is going to change. You need to welcome that change and look at how you can make that adjustment to help the business realize the value of that change. 3. Work Together Daily The next Agile principle of my top 5 is work together daily and this is all about the business working with other project team members such as the business analysts and the developers and the quality assurance members etc. So we’re working together daily, having conversations, making decisions and moving things forward. Too often in the waterall or traditional methodologis because of the variosu stages everybody’s siloed, the business analyst is very siloed, they may be working with the busines, but then they need to translate all those details to the developers. That developers siloed, they work only with the business analyst, who transaltes the business needs so if there’s questions the business anlayst has to play the middle man. Agile is saying work together, everybody is going to work together and everybody will work together every single day. We’re one big team driving towards one specific goal, we need to work together daily. 4. Working Software is Key Next is working software is key. And I picked this one because a lot of times in traditional methodologies as you’re working through and gathering requirements and creating models you feel like you’re really making good progress and you are, but you have to remember that when you’re doing that you’re not actually creating any value for the business at this point, you’re just creating the models and the requirements to then be able to create some type of solution that then can create value. Where Agile is a little different. They’re only focussed on the working software. They don’t care about all the models and requirements you have to do in the back end, that’s all just means to get to that working software, that working solution. So the working software is the primary focus and the primary measure of how the project is moving forward. 5. Reflect And Adjust And last but not least I chose reflect and adjust. Agile being a very iterative process, it allows the team to reflect on what happened in that last timebox, that last iteration and make adjustments, to their processes, make adjustments to roles and responsibilities, make adjustments to how they’re delivering that value to the business. By making those adjustments you’re able to do those lessons learned over and over and over throghout a project. And by the end of the project or really by the middle of the project, most project teams are feeling like a well oiled machine. Everybody just knows what they’re
- 5. 5 doing. They are working through. A lot of the issues and problems and challenges have been resolved and everybody is just striving for that end result. On more traditional projects, like a waterfall type of project, you only get to do a lessons learned really at the end of that project, so after the six months, two years, three years, whatever the project length is, then you sit down and do a lesson learned. But you’re thinking back through six months, two years, three years to do a lessons learned. Good luck remembering all the challenges that happen and making adjustments. That’s one of the bummers. But the other bummer is, you don’t get to utilise the lessons learned that you learned on that project that you just got finished with because that project’s done. Now you need to try to apply those to the next project. Benefits of Agile Agile was created because of the pitfalls and downfalls of a traditional waterfall methodology. You see with waterfall there’s various phases and you can’t move to the next phase until the previous phase is complete. And once you’ve move passed a phase, it’s very difficult to go back to a previous phase. So for waterfall you need to identify all the requirements upfront, then you need a model and analyse all those requirements. Then you need to develop some type of solution that meets those requirements. Then you go through the testing and move to the production phases. But if you are already in the development or testing and you identify some changes, to go back it takes a lot of work for that team to go back to requirements and push that as a sperate piece through that waterfall process. As well, because of having to do those things step by step by step the value isn’t delivered to the end user and to the customer until the end of the process and so it causes a lot of problem. As well, with waterfall it’s a much longer period to deliver any type of value or gain any feedback from the users or the customer that ultimately asked for this solution because you have to gather all the requirements, go through design, development and testing, that is months, sometimes years to actually receive some type of solution that may or may not meet the business need. Agile was created to help solve those problems. The number one thing that Agile does it allows you to deliver that value in smaller increments to the customer. Not only as a customer that end users get to start utilizing that solution and seeing that value, but also they get to give you feedback. They really like it or they don’t really like it or this should be adjusted or the business has changed. Agile allows you to do that, you deliver that little bit of value, you gain that critical feedback that will change and adjust the way you move forward on your project. And it really helps to solve a lot of those problems before they become big problems. And because Agile is more of an iterative process, the project team is actually able to get feedback on their performance as well. The project team can understand what they could do differently and what they could adjust to make them even more successful and make their solution even more successful. Challenges of Using Agile So now that we’ve talked about some of the benefits of Agile. Why aren’t all companies using this? What are some of the challenges to using Agile?
- 6. 6 While the first thing is agile is actually difficult for exiting companies and organisations to implement if they’re using some type of methodology like waterfall or other methodology today. And the biggest reason is agile changes everything. It really has to change the whole mindset of the company. It sometimes has to change the organisational structure, has to change the way people and teams in various roles work with each other. And it really has to be an all or nothing process. So lot of companies will kind of go into and to move in the Agile and they’ll do it half heartedly because oh yeah we want to get better and we want our solutions to be out faster and we want to receive all those benefits of using it. But they do it half heartedly and in the end years down the line, they’re still using a half agile half non agile approach. And let’s just say it doesn’t work. So that’s one of the big challenges is companies have to be all in and ready to spend some money and a lot of time in making that adjustment. Now we’re saying that new companies starting up have a much easier time of making this work. And that’s because they don’t have exiting processes or various things that need to be adjusted. And that company culture can just be built around that Agile philosophy and that Agile mindset. One of the really nice things that a lot of team members like about Agile is the real lack of documentation, honestly, agile really focuses on more on conversation and communication than writing all of these requirements out in building models and all that stuff. Agile really has that all done through let’s sit down, let’s discuss it, let’s hammer it out and then we will move forward on whatever is decided there. That can pose some real challenges when the project is over. And now you have maybe a support team handling this situation that was created. Well, there’s not any real documentation to tell that support team how it works or some of the common things that come up, it can be a big challenge for them to learn and support that particular solution. And while we’re talking more documentation, another challenge for the lack of documentation is reusing features or components. In a traditional methodology such as waterfall you’re documenting those features out, you document the design, you document all the analysis points that you’ve really thought about as you’ve designed it and as you’ve developed the solution and that feature, that component can be utilised on additional projects so if you’ve additional projects later that are very similar, you can utilize that documentation to implement that feature on that next project. Because of Agile not having much documentation and really that information only being stored or really siloed by the project team members that worked on that particular project, it can be much more difficult in Agile to take a feature from a previous proejct and successfully apply it to the new one. And the last challenge we’re going to talke about is really there’s not a clear role in Agile that takes control or has ownership of that particular project. Instead, the team works together collaboratively and everybody chips in and does their part to make sure that the project meets that eventual business need. The challenge arises when the project goes off course, when it kind of goes into an area that wasn’t planned for. Now there’s no real role inside of that team to help bring it back. Everybody in the collaborative teams kind of looking at each other and not really sure who should be stepping up to correct the path and get back on plan.