Many of you might have heard of agile project management. It is catching the world by a storm and is especially popular among software development firms. Let's talk a little bit about what is agile, where it came from, what are its origins, what's its mission and how might it be relevant to the project that you're about to start. Well, the background behind agile has to do with software development firms around the year 2000. Many of the firms were growing. Firms that started as small start-ps were building a reputation, were successful, and acquiring a larger size development team. As a result of the company growth, what happened in return was a slowdown of the release pace, meaning the release schedule was slowed down. They were releasing the product to the market not as frequently as they wanted to, or not as frequently as they did when they were small and nimble. In addition to a slower release pace, the quality of the product also declined, and there was a bigger mismatch between what the customer wanted and the product that was being delivered. The engineers that were working on the on the products were feeling the hit, the morale was low. They wanted to be part of a small and nimble company where they touched the customer and they felt the impact and the benefits of their development. They wanted to be proud of their work and they wanted to know that when they work, it immediately affects a customer out there. And in addition, because of this, they were padding the durations of their tasks, and they were not accountable or defending themselves in terms of how they stuck up for their work, or how they would step up to help correct problems as they emerged. And so these phenomena that occurred in several different companies, Salesforce.com is one example, a customer service company out in in the Silicon Valley. They felt the need to make some changes. They felt that the traditional project management tools and the way that they organized their company and the way that the work was being performed was not standing up to time and to the growth of their firm. And so a group of 17 visionaries came together around the year 2001 and decided to sign what they saw as the vision of software development, the Agile Manifesto. They collaborated on a document to come up with a set of principles that would guide the way that they thought about software development. They focused on a few items. First and foremost, they value individuals and interactions. They were going to focus on delivering working software. And on customer, and constant customer collaboration. They were going to be looking at responding to change and not necessarily following a predetermined plan that was set up up front. And so, while they understand the need for documentation, and engineers and the firms in which they work in also understand the need for, for a general plan. They valued these ideas that are listed in bold more than they valued the others. They knew that if they were able to address these, these components by putting more emphasis on the customers and their needs, on the interaction between the teammates. And on the fact that they would like to deliver working software, they would stand a chance to improve, a chance to improve the performance, and improve the situation for everyone. The customer and their engineers within. A few principles were drafted. Quite a few principles were drafted as the backbone to the manifesto. How would they execute on the manifesto? How would they make this vision come to life? And so, of the list of the, of principles, that are on the screen in front of you,. Focus on the first one, for instance. The highest priority is to satisfy the customer through early and continuous delivery of valuable software. That is a principle that guides the agile approach that addresses or tries to live up to the manifesto's components. Constant working software delivered to the hands of the customer to allow for a more interactive approach to developing a product. And so following the manifesto and following its 12 different principles, they came up with quite a few mechanisms by which we can execute and actually implement the agile ideas. I will talk about two of these mechanisms. The first is through what they call Scrum Sprints. Borrowing terminology from sports and from rugby specifically, the idea with the scrum approach is to work in an iterative fashion, to limit the amount of work and to work in small iterations in a very collaborative fashion. In order to ultimately deliver to the customer working product. In addition to the Scrum approach, or the Scrum Sprints approach, in which each iteration is a sprint, there is another way in which we can work in an agile format. And that is following a Kanban approach. The Kanban, borrowed from manufacturing arena, has to do with working continuously, limiting the amount of work in progress at any given time in a system, but constantly delivering output. Constantly handing off functionality to our customer at the end of the day. And so whether you're working in defined sprints and following a Scrum approach, or whether you're working in a Kanban mechanism in which you're constantly delivering to the client but limiting the amount of ongoing work, you're still working agile. You're working in small units of work, of pieces of work. You're working in small cohesive teams. And you're putting the customer's needs and the idea of devel, delivering a working software as a top priority. Let's dig in a little bit to what is required in order to work with our Scrum approach. What kind of mechanisms do we need in place to make sure that we can actually execute on the Scrum principle and deliver a product to the hand of the customer with short iterations. First, we must have a Scrum Team. The Scrum Team is very well-defined and it is a necessity to have it in place in order to work in this fashion. We need a group of developers. They need to have a Scrum master who has been trained as a Scrum master. A Product owner that serves as a liaiser between the Scrum master and the team and the Customer. And we need a Customer involved throughout the entire process. The group of developers have to be cross-functional, because it will require to complete the entire steps that are necessary to deliver a working product. If that means we need a coder, and we need somebody to do the QA, then we need them all working together as part of a Scrum team. It is self-organizing, they have the capability with their Scrum master to vet which features they can conduct and they can execute on and what might they need in order to push the needle forward. The Scrum master is in charge of taking care of the Scrum Team. He is in charge of blocking and tackling anything that might get in their way. He is in charge of coordinating the different individuals and allowing them to help each other and to have a constant flow of information among them. The Product owner is the one that sets the priorities. What should the team be working on in this specific iteration? And the Product owner gets that knowledge from constant dialogue with the customer. How did they value the previous features, and what would they like to see in place in the next iteration? This scrum teams works together during a sprint. They work on many sprints in a given year. The sprints are typically anywhere between one week sprint to four weeks of, four week sprint. And the idea of with the sprint is that we work intensely on a set of ideas or a set of features that we've defined at the beginning of the sprint. And that at the end of the sprint we deliver a product to the customer. Typically firms start off with a product backlog, a list of features that need to go into our product at the end of the day, or a list of features that together, with the customer, we've identified as worthy of working on. At the beginning of the sprint we will identify what goes into the sprint backlog. Which features are we putting in front of us to work on, say in the next two weeks? During the next two weeks in an iterative fashion, the team members take whatever they're comfortable with, whatever piece of work they're expert in, and they progress on the work on delivering those features. They might iterate among themselves using code, doing some documentation, checking it out and fixing some bugs. Or they might wait, work in a more sequential fashion. But that is up to them, to the self-organizing team. At the end of the sprint, they deliver whatever works to the client. They deliver a working feature to the client. What's crucial in the sprint is maintaining and monitoring the different, and making sure that you execute on the different meetings that are scheduled. The meetings set the tone for the entire sprint and they ensure that the sprint delivers on its promise. It delivers a working product to the customer and the team is satisfied in the way it's working together. These are the meetings that we need to ensure that occur throughout the sprint. First, we start off with a sprint planning. We plan which of the items from the product backlog go into our sprint backlog. Then during,the execution, during the sprint itself, we go through a daily stand up, a daily scrum meeting, a standing up meeting. No one sits down. Maybe 15 minutes in which we share our experience and flag, or raise some flags, if need be, if we are reaching some problematic area. We talk and communicate as to what we're planning to do that day, and what we were able to achieve the day before. Those daily stand up meetings are vital as we progress through the scrum in its quick and rapid pace. Once the product is ready at the end of the sprint, we conduct a sprint review, and the customer's in the sprint review helping us understand what they feel about the features that we've developed and how they might be using it to test it out. And finally, we conduct an internal Sprint Retrospective, reflecting on what went well and what did not go as well and how we can improve in the next sprint moving forward. Agile has some immediate benefits. It empowers the development teams. It allows them to feel that they can work on the items that they feel they would like to, at the pace in which they prefer, and they can work together, and they have each other's backs. They feel a quick turnaround in satisfaction and working closely with the client in developing something that the client wants. We build the right thing at the right time and build it right. There is little ambiguity in the fact that the client actually will use it because it was agreed upon with the customer just a week or two ago. It helps us have a, a collaborative atmosphere and a transparency with our client. We are not negotiating over contracts that might take a long time, but we are agreeing to work and to be in constant contact to ensure that everybody is satisfied. However, there is some contention. There is some disagreement or some struggle, to have a unified approach to agile, and it doesn't always fit or doesn't always match with our company's setting, and with, in, and the project that we're about to start. Here are some contentions around agile. First, we need to be okay with a living in the moment culture. The features that we develop are determined perhaps a week or two ahead of time. We may not know what exact features or products we will be working on in a year or two's time. And we need to be okay with that. And that needs to fit the type of product that we deliver. We ultimately are going to have less documentation. We're going to be working on smaller features and we are going to develop them quicker. And we're not going to spend as much time writing every single instruction out in the same way that we would a traditional product. Third, there is some resistance to estimation at all in the agile domain. Those who believe in the agile approach, they do not want to spend time estimating how long a feature will take me to develop. Or whether or not it should be included in the next sprint, but they just want to get in there and get started on working on that feature. Believing in the fact that it will be developed and it will deliver value, and the highest value to the client. The no estimates idea is sometimes a struggle to fit in the context of the larger organization and the planning necessities that the organization might have. It is hard to master. We need to set the tone right. We need to meet as frequently as the sprint is. We need to conduct those meetings almost religiously to ensure that we actually are applying the agile properly. And ensure that we can actually deliver a working software to the client at the end of the day. Not everybody and not every environment is suitable for this type of work. Perhaps the work cannot be divided into smaller chunks and we can't work in a modular way. And finally, if we have many distributed teams across the globe, finding time for daily stand ups or working collaboratively and helping each other out on our tasks might not actually physically be possible. And so it might not always be ideal for us to work in this way and maybe we need to identify where our organization lies. How is our project going to be executed? And whether or not the tools that we've introduced so far are appropriate. In many cases, we might find ourselves picking and choosing. We might do some documentation and proper planning following a critical path and coming up with our Gannt Chart and actually execute our project using earned value analysis. We may choose a specific sub-group or a specific functionality within our larger project to work in a more agile way. Assuming it is possible, we have a customer that will collaborate and interact with us. And we have a small enough team that can be devoted to the project and can work together to deliver small units of work and, during quick iterations. Having the tools to identify what is needed for each methodology to, to work and to be successful is a vital part of being successful as a project manager and ultimately executing on a meaningful and successful project.
