6. What is Agile?
What is agile. Agile is definitely the latest and coolest buzzword in the software development world. These days. Everyone wants to be agile. But there are many misconceptions of what agile means and many people don’t fully understand the implications of what it takes to develop an effective agile development process. It’s very important to understand what we are getting ourselves into before taking any step. First, let’s talk about the meaning of the word Agile. Dr. David Rico defined Agile as follows the ability to create and respond to change in order to profit in a tough global business environment. It’s also the ability to quickly reparative use of resources when requirements, technology and knowledge shift or change.
It’s also a very fast response to sudden market changes and emerging swifts by intensive customer interaction. Agile is use of evolutionary incremental and Iterative delivery to meet an optimal customer solution. It’s also maximizing the business value with right size, just enough and justintime processes and documentation.
From the project management point of view, agile is innovative software development but with more best practices to deliver a software with better quality at a lower cost in less time by highly motivated people. Wow, this is a big one. So let me repeat again. Agile is an Iterative software development but with more best practices to deliver a software with better quality at a lower cost and less time by highly motivated people. We still use the same concept of iteration and continuous delivery of a working software to the customer after every iteration.
Azure development has become commonplace in It industry. In a recent survey, over 52% of response said that the company practiced Agile development in one form or another. That is something that I want you to notice, they said one form or another. Which means that there are different forms to use Agile in your project and we will talk about this in detail in future videos. So let’s understand Ajayal from the first day It was born.
7. Agile Manifesto
In 2001, a group of very well known names in the software industry, representing the most widely used lightweight software development methodologies looked at the software industry and how does it advance? And they didn’t like what they see. They looked at the issues and came up with a solution which they called Agile. They agreed on a common set of values and principles which became known as the Manifesto for Agile Software Development or the Agile Manifesto. The way I look at the Agile Manifesto is as any country’s constitution, this is the base that all the laws of that country should arise from. No law is allowed against the Constitution or the Manifesto. Let’s read it together. We are uncovering better ways of developing software by doing it and helping others do it.
Though this work, we have come to value individuals and interactions over bosses and tools. Working software over comprehensive documentation customer collaboration over contract negotiation 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 Agile Manifesto contains four statements of values. Let’s look at each one of them in detail. First one individuals and interaction over processes and tools. Software projects are people oriented. Much of our success is based upon effective interaction and communication. Even if we have the best processes and tools, but combined with poor communication, success will be very likely. Processes and tools are well, tools. They are not the objective or the goals that we must follow. They are, after all, tools.
Any processes and tools should be used as enabler to increase the teamwork rather than replacing it. Projects are developed by people, problems get solved by people, scope is defined or negotiated by people and most importantly, projects are accepted by people. Focusing early on developing the individuals involved in the project and emphasizing productive and effective interactions help set up a project for success. Please please note that this is not to say that BCC’s and tools cannot help in successfully completing a project. This is a common mistake done by companies who are starting to use Agile. They think Agile means no processes. Wrong. Our projects are ultimately about people. If we ask two teams to develop the same border, they will produce different algorithms. Yes, it’s the same software that helps with the same objective.
But the requirement document will be different, the design will be different, the code will be different. Even how to test the software will be different. Everything will be different. Why? Because we depend on how people think, which varies from one person to another. Working software over comprehensive documentation software without documentation is certainly a problem and will truly hold back support and maintenance. But comprehensive documentation without software is next to zero valueless to most organizations. Software projects are typically initiated with the goal of creating valuable high quality software, right? Even though this is very common sense, it still has been weeks or months writing extensive documentation that doesn’t support the ultimate goal of creating software.
From the customer perspective, working software is much more useful and valuable than very detailed documentation. In addition, because working software is available much earlier in the software development cycle, agile development can provide significant time to market advantage and it provides an opportunity to give the development team rabid feedback.
I remember in my early days in the 80s when I started to learn about waterfall, I had to read like thousands of pages to understand what is the required documentation in waterfall. And of course I had to create or reduce those thousands of pages or reports myself. Again, a very common mistake where people claim that Agile promotes no documentation wrong. This doesn’t mean that we have to avoid documentation completely, but only necessary documentation is reduced. And for me this is an art to document only what is necessary. Do I need to document that? The form used in reboot XYZ it’s times on New York.
No, I can see it. So who I recorded in a document. So this means that valuable software will be delivered early and frequently during the development. So in Agile way of working, we deliver a piece of working software increment every iteration. That means we need to decide what to deliver in every iteration and decide if a specific feature will add a value to the user or not. This value speaks about the need to deliver customer collaboration over contract negotiation. We all should know by now that customers often find great difficulty in specifying the assistance that they require. And this is very natural. My friend. If you are a single person or when you were single, could you specify exactly what do you want in your future spouse? I doubt it. It’s very hard to define exactly an unchanging view of what you want to build. Well, you see prototypes, you see this and that, you see different versions and then you can build from what you saw, what you are actually looking for.
So this value reminds us to be flexible rather than uncooperative. It’s similar to the difference between verification and validation. Verification doing the thing right and validation doing the right thing. Again, we value both verification and validation, but we should value validation over verification. I will explain we could do verification and testing to build the product exactly as originally specified. But if the customer changes his mind or her mind or claims that this will not help them in their business, it would be better to be flexible and work toward the new goal as opposed to the goal that was originally stated. Validation doing what the customer wants, verification doing it in the right way. Software products have a dynamic nature. Software is intangible.
Business needs change quickly, technology changes rapidly. Rather than beat up the customer or management with a very tough change management to process, we should recognize at the start that things are going to change and we should work with the customer throughout the project toward a shared understanding of how to define that something is done. Collaborating directly with the customer improves the likelihood of understanding exactly what the customer requires. Working in a regular and close collaboration with them is likely to bring more understanding and success to the project. Customers often do not know what they really want until they see something. Working while having contracts with customers is important, azhar Boom Oats are more trusting relationship and more flexible contract models than we often see on to additional projects. Writing contracts with the customer is a profit motive and collaboration is a purpose motive. So purpose motive should be given more importance than profit motive. Responding to change is over following a plan so we agree that a change is inevitable in software projects.
High rates of a change are common in software projects many factors might require the change. These factors must be accumulated by the development process. Also, the initial blends were made when we knew this about the project at the beginning of the project and as the work progresses, we will learn more about the work and we should update the plan accordingly. The flexibility to accommodate changes into the plan is more significant than just to writing a plan and following it. We need to acknowledge that things will change and blend smartly again and again. This doesn’t mean that Ajai Manifesto is suggesting that we abandon blending and just to react to changes. No, we still need to blend, but we need to blend smartly.
So the Ajai Manifesto guides us to consider projects from a value based perspective. Yes, we will need BCCs tools, documentation and the blends on our projects. Yet while dealing with those assets, we should remember that our focus must be on the people engaged the product that we are building. Cooperation and flexibility agility is the ability to execute projects while focusing our efforts on the items on the left in the Azure manifesto over the items on the right.
8. Scrum
Another agile development framework that has several key features that are shown in the figure and we will explain each one of them in detail. Scrum defines three roles scrum Master who ensures that Scrum practices and rules are understood, implemented and followed and resolved with any violation resource issues of of other barriers that could prevent the team from following the practices and rules. This person is not the team leader, but a coach. For me, I consider him more of a quality assurance person, but that’s only my point of view. Product Owner represents the customer who is responsible for maximizing the value of the product. Has the sole responsibility of managing the product backlog, including its biritilization accuracy, shared understanding, value and visibility. Again, is based on is not the team leader. Development team is a group of professionals who can fulfill all the roles needed to complete the work and build the product increments.
In each iteration, the development team is empowered to manage its own work and its members are self organizing and cost functional. They develop and test the product. Again, there is no team leader, so the team makes its own decisions. Scrum contains the following instruments and practices a Scrum divides a project into iterations of fixed lens cold sprints and a Scrum and the lens is usually two to four weeks. Every iteration should attempt to build a potentially shapable and properly tested product increment. The time duration for the sprint and how long it lasts is decided by the team based on their requirements and capabilities. Sprint duration, once agreed upon, should not be modified, which means if anything unusual happened during the sprint that requires extra time, it should be moved to the next sprint. A sprint is like a minibojit. During the sprint, no changes are made that would affect the sprint goal, although the scope may be clarified or renegotiated as new information becomes available.
Each sprint includes as print planning meeting, daily Scrum development work, as print Review meeting and as Print Retrospective. We will talk about those events in future lectures. The development team members are kept the same throughout the sprint. Product Increment each sprint results in a potentially releasable shippable product called an increment. Product Backlog the product owner manages a birthatized list of blend product items in a lock called the product backlog. The product Backlog is the ordered list of everything that might be needed for the product to be built. The product backlog serves as the single source for requirement. It is dynamic and evolves as the product evolves from Sprint to Sprint. Called backlog refinement, it contains features to be built, functions, requirements, nonfunctional requirements and fixes. And whatever needs to be done is idly expressed such that each item has value to the users or customers of the product.
The product backlog by authorized by the product owner and refined at the start of each iteration. Grooming is the process of adding more detail and order to the backlog and refining the estimates of the backlog items. Sprint Backlog At the start of each print, the Scrum team selects a set of the highest priority items from the product backlog and put it into the Sprint backlog combined by a plan of how to achieve the Sprint goal. Since the Scrum team, not the product owner, selects the items to be realized within the Sprint, the selection is referred to as being on the poll principles rather than the push principle. Poll Principles the developer is pulling the items from the product backlog and put it in the Sprint backlog and not the product owner pushes the item against the developers. The Sprint backlog may only be updated by the development team. Definition of Done The team should collectively create the definition of done for the items before they begin to work on them.
This helps to make sure that there is a potentially releasable product at each Sprint’s end. The Scrum team discusses and defines appropriate criteria for its rent completion. The discussion deepens the team’s understanding of the backlog items and the product requirements. Time Boxing Time boxes are short, fixed duration periods of time in which activities of work are undertaken. If the work blend for the time box is not complete when the time runs out, then we stop what we are doing and move the uncompleted work into another time box. Examples of time boxes include daily standup meetings that are timeboxed to 15 minutes, iterations that are timeboxed to typically two weeks, and so on. As we mentioned before, only those tasks, requirements or features that the team expects to finish within the Sprint are part of the Sprint backlog.
If the development team cannot finish a task within a Sprint, the associated product features are removed from the Sprint and the task is moved back into the product backlog. Transparency the development team reports and updates brand status on a daily basis at a meeting called the Daily Scrum. This makes the content and progress of the counter’s brand, including test results which should be visible to the team management and any interested party. For example, the development team can show his brand status on a whiteboard. It’s so simple. Unlike XP, the Scrum does not dictate specific software development techniques like pair programming or test first programming. In addition, Scrum does not provide guidance on how testing has to be done in a Scrum budget.
