Fundamentals Of Agile Software Development | Jimmy Mathew | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Fundamentals Of Agile Software Development

teacher avatar Jimmy Mathew, Agile Consultant

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

5 Lessons (28m)
    • 1. Lecture: 01 Course Introduction

    • 2. Lecture: 02 Agile Software Development

    • 3. Lecture: 03 Agile Manifesto and Principles

    • 4. Lecture: 04 Agile Methodologies

    • 5. Outro Our Classes in SkillShare

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

*Updated as per the latest Scrum Guide, Nov 2020. We have updated the course content as per the changes made in the latest version of the scrum Guide(TM)

Fundamentals Of Agile Software Development. This gives all required basic knowledge on agile software development.

This is a good starting point or a quick refresher on Agile.

Agile Fundamentals, Agile Manifesto and Principles, Overview of Agile Approaches, Frameworks.

This course explains the fundamentals of Agile Software Development.  This training is designed to provide some basic information on agile software development, a discussion on agile manifesto and principles and an overview of different Agile approaches.

A basic knowledge of software development will be helpful, but not a prerequisite for this course.

This course is for anyone who want to learn or expand their knowledge on Agile Software Development. Anyone associated with, planning to get involved in or interested in learning more about Agile software development can use this course.

This course is complied with a subset of lessons from our scrum training, i.e.  "Scrum Training" and "Agile, Scrum Training with Interview Questions, Interview Preparation for Scrum Master, PO roles".


Topics covered as part of this course are...

Agile Software Development

Agile Manifesto and Principles

Agile Methodologies



    Extreme Programming(XP)

This course has some references taken from the Agile Manifesto and principles behind the Agile Manifesto. The Agile Manifesto is available at agilemanifesto org and the principles behind the Agile Manifesto are available at agilemanifesto org/principles html. Please have a quick look at these.

This course is neither endorsed by nor affiliated with Scrum org. This course uses content from the Scrum Guide. All the content related to Scrum Guide is taken from scrumguides org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at http://creativecommons org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons org/licenses/by-sa/4.0/. 

Meet Your Teacher

Teacher Profile Image

Jimmy Mathew

Agile Consultant


Around 15 years in IT, 7 years of Agile experience, playing various roles of Agile Coach, Scrum Master, Trainer, etc.


Book: - Scrum Tales: Stories from a Scrum Master's Diary  

Book: - Agile Life: Understanding agile in a non-software context  



.      ICP-ACC - ICP Agile Coaching   

·      CSP – Certified Scrum Professional  

·      CSM – Certified Scrum Master  

·      SAFe - Scaled Agile Framework-Agilist  

·      PSM1 – Professional Scrum Master  

... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Lecture: 01 Course Introduction: Welcome to the Fundamentals of Agile software development. This gives all required basic knowledge on Agile software development. This is a good starting point or a quick refresher on Agile. Agile fundamentals, Agile Manifesto and Principles, overview of Agile approaches, frameworks. This course explains the fundamentals of Agile software development. There's training is designed to provide some basic information on Agile software development. Our discussion on Agile Manifesto and principles and an overview of different Agile approaches. This course is for anyone who wants to learn or expand their knowledge on Agile software development. Anyone associated with planning to get involved in or interested in learning more about Agile software development can use this course. This course covers an introduction to Agile software development with a detailed discussion on the Agile Manifesto and principles. This has brief discussions on different agile methodologies like Scrum, kanban, XP, et cetera. 2. Lecture: 02 Agile Software Development: Hello, Welcome back. In this module, we will have an introduction to Agile software development. In the traditional waterfall approach, the software development is done in a sequence of phases. First, there will be a detailed requirement phase. In this phase, the complete set of requirements are captured. Then we will move to a design phase. We will complete the high level design, low level design, et cetera. Then we will start with the development, followed by testing and then user acceptance and release. This looks fine as a solid framework, but here we are dealing with human beings, not machines. Mistakes can creep in. For example, requirements may keep changing as the development progresses. Development may take too long or at the end to keep schedule, we may have to skip some tests knowingly or by mistake. It is a long time period from the requirements to the delivery. We don't realize any value until the end of the project. And when we realize it that the customer's needs may not remain the same. This approach leaves the testing until the end. Mistakes are detected late and it will be costly at effects. We don't seek approval from the stake holders until late. There's no frequent interaction with the customer. And when we show them the product, it might not be the right product for them. The planning is done and thanks early in the project and we are managing the project to the plan. There's a heavy dependency on the plan. This traditional approach is heavily reliant upon a project manager driving the way. Now let's start with Agile software development. If we go for a simple definition, it says agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration and delivery at timebox iterative approach and encourages rapid and flexible responses to change. It is a conceptual framework that promotes forcing interactions throughout the development cycle. There are a few key words highlighted here. We will discuss them one by one in the coming slides. Agile methods are based on an iterative and incremental development approach where requirements and solutions evolved through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, and delivery at time-boxed iterative approach and encourages rapid and flexible responses to change. Agile is an umbrella term for different methods such as XP, Scrum, and ESDM. Agile is much more than a new process. It is a culturally different way of building products compared to the traditional methods. Now let's discuss two concepts, incremental and iterative development. In the integrative model, the entire development is split into a number of parts. Instead of having a long single phase, the development happens in different smaller iterations. Iteration development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, the software is designed, developed, and tested in repeated cycles. As the name suggests, in the incremental model, where development happens in an incremental way. Instead of delivering all at once, we start with an initial one and keep adding increments to it. The increment bold model is a method of software development where the product is designed, implemented, and tested incrementally. That is, a little more is added each time until the product is finished. The next topic is self-organizing and cross-functional teams. Self-organizing teams plan and manage their work on their own, not directed by someone outside the team. Self-organizing teams choose how best to accomplish their work rather than being directed by others outside the team. Teams are structured and empowered by the organization to organize and manage their own work. A cross-functional team has the right mix of capabilities. They all have the required skills to successfully complete their work. A cross-functional team is a group of people with different functional expertise working toward a common goal. In other words, the team will have all the capabilities to accomplish the task assigned to them. Now, let's discuss a few points on planning. In traditional software development, planning is predictive. The plan is defined at the beginning of a project and then managing the project to the plan. In adaptive planning, we define an overall plan at the start, but it is not frozen. Once work starts, the blend may change to adapt to the new learnings and changes around us. Lands for an Agile team will be adapted based on the delivery and changes in the requirement for each iteration. Benefits of agile include not limited to accelerate time to market. Agile delivers the right scope at the right time, not all at once. The most important features are delivered earlier than later. It increases project transparency and visibility by having multiple iterations of the end-to-end development cycle rather than one iteration. Agile methods welcome changing requirements. It addresses evolving requirements and re-prioritize is as needed. Reduce risk and overall cost was short delivery cycles. And testing early and often do identify potential issues early in the project. Business and developers work together throughout the project. It improves collaboration and alignment with business organizations. In the traditional approach, the plan is a onetime activity. But in Agile, planning is done at different levels. We will have initial upfront planning at the start and just in time planning in iterations. In the traditional approach, the project manager plans for the team, but an agile team is empowered and participates in planning. In the traditional approach, detailed requirements are captured and frozen upfront. But an agile we have high level requirements to start with and requirements evolve as the project progresses. In the traditional approach, we have huge requirements documentation, a lot of taxed at different levels. But an agile requirements are captured in the form of user stories or user cases in a simple way. In the traditional approach, limited client collaboration of the requirements definition. But in Agile, we collaborate with the client throughout the project life cycle. Now let's see some of the key drivers for adopting Agile. A recent survey lists down many benefits as listed here. You can visit the website given below for more details. A few of the drivers, our ability to manage changing requirements, more visibility, more productivity, better times a market, better business alignment, et cetera. Je, IT planning. Jit stands for just in time. In this approach, we have a high level plan for a long duration. Detailed plan for a short duration. Detailed plans are curated at the time they are needed, not months in advance. Decisions are made at the last responsible moment. This reduces rework and re-plan. With this, we have reached the end of this module. In the next section, we will discuss the Agile Manifesto and principles. 3. Lecture: 03 Agile Manifesto and Principles: Welcome to this module. Here we discuss Agile Manifesto and principles. Let us start the discussion with the four core values of Agile software development in the year 2000. And one, a group of 17 lightweight methodologists met in the Salt Lake Valley. The meeting included the representatives of different methodologies existing at that time, like extreme programming, Scrum, the ESDM, adaptive software development, et cetera. They've come up with something called an Agile manifesto. It was written in the form of a over b. It says, we are uncovering better ways of developing software by doing it and 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, responding to change over following a plan. Now the last sentence is very important. This is a point that will clear many of our questions. That is, while there is value in items on the right, we value the items on the left. More. Journalists, not against processes, documents, contracts, or plants, but there are other items that we value more. Let's discuss these items in detail. Individuals and interactions over processes and tools. Processes are good, but we should not underestimate the power of interactions and face-to-face conversations. We are not doing any factory work where machine can produce an items in given time. We are in a knowledge industry where the focus should be on empowered, self-managing, cross-functional teams. This doesn't mean that Agile is against the processes and tools they are required, but they should support these interactions. They are not for replacing the interactions. Working software over comprehensive documentation. Traditionally, we rely on a lot of documentation. We have a requirement phase where we created and sign off the requirements. Then high-level, low-level designs create a detailed design document. All these are part of our project execution and have weights associated. So we will say that a percentage of work is done, but we have not actually delivered anything that can be used by the end-user. Our aim is to deliver value to customers, not a big load of documents. Working software should be our primary output and measurement of our progress. It doesn't mean that we should not document. We should have a minimum required documents. Another issue is maintaining the huge set of documents. We have a detailed design spec and many times towards the end of the project, we find it to be obsolete because we don't maintain it. So go for minimum documentation which is properly maintained. Let code talk for itself as much as possible. Customer collaboration over contract negotiation. What do we do? Traditionally? Customer gives as the requirements and we give them the product. In other words, the customer throws the requirements over the wall and we throw the product back. In Agile, customers become part of the development process. Customer and vendor together trying to serve the end-user. And Joel never says that we should not have a contract. It is very important and it facilitates everything. It gives us the authority to do the work and it guides us. But we should be flexible enough to support close collaboration among all parties. Responding to change over following a plan. What do we do? Traditionally, we have a big project. We plan it through completion. We have a sequence of tasks. We have a critical path, leads and lags, early start date, late finish dates, and so on. We start analyzing variants and reconsider changes as an exception, but not in Agile. In Agile, changes are expected. We don't create such a long detailed plans. We have a roadmap and overall plan for long time and a detailed plan for a short future. We don't create a detailed plan on something that we are not sure about. It is like we walked for a small distance, stop, look around and cover another distance. We planned in the last responsible moment. We do plan, but follow kind of rolling wave planning. So we have covered the core of the Agile Manifesto. Let's have a read lock. Individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. Now let's review the principles behind the Agile Manifesto. The Agile principles sense our highest priority is to satisfy the customer through early and continuous delivery of valuable software. We have discussed the manifesto items, working software over comprehensive documentation. What customer needs is value. The working software. Not a set of documents. We proceed in a series of iterations and deliver increments frequently. The Angelo principle says, welcome changing requirements even late in development, agile processes harness change for the customer's competitive advantage. We have discussed a manifesto item, responding to change over following a plan. The Agile approach tries to accommodate changes as efficiently as possible while maintaining an awareness of its consequences. Everyone agrees that constant feedback is great, but often ignores that the result of accepted feedback changes. Agile believes facilitating change is more effective than attempting to prevent it. The Agile Principle sense, deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter timescale. This is Read Along with the first principle. We frequently deliver in shorter periods. This helps us to accommodate changes as per the changing values and customer feedback. The Agile principles sense business people and developers must work together daily throughout the project. The key word here is daily. It is no more throwing the requirements over the wall. We worked together with businesses and deliver value to the end customer. The business gives us the direction and teams deliver the value. Agile principle says, build projects around motivated individuals, give them the environment and support they need and trust them to get the job done. Great processes with state of the art tools don't guarantee success. It is motivated self-organizing teams that define success. We should provide them with support and trust them. Bian Jiang principle sense, the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. There's a famous statement. Knowledge cannot be transferred by getting an out of people's heads and putting it on paper. The best and most effective way of communication is face to face conversation. People interacting with each other comes out with more valuable results. The Agile principles sense, working software is the primary measure of progress. We have discussed this point in detail. It is the value we deliver, not the documentation that defines success. The Agile principles sense, agile processes promote sustainable development. The sponsors, developers, users should be able to maintain a constant pace indefinitely. The keyword here is a constant pace indefinitely. It is not working 24, 7 from the beginning and try down towards the middle. It is not keeping all the work to one month before release. It is all about maintaining a constant pace that can be sustained over a long period of time. The Agile principles sense continuous attention to technical excellence and good design enhances agility. Design cannot be a purely up-front activity to be completed before construction. Instead, design is a continuous activity that's performed throughout the project. Each and every iteration we'll have designed work. But our design must be flexible and efficient to accommodate the changes. The Agile principles sense simplicity. The art of maximizing the amount of work not done is essential. We make it simple. We trying to achieve maximum value with minimum work. We avoid unnecessary complexity both in process and in value. We concentrate on delivering value, and we will try to avoid all postpone activities with lesser value and concentrate on the core activities. The agile principle says, the best architectures, requirements, and designs emerge from self-organizing teams. It is multiple brains works in a synergic way. They organize themselves for better results with the visibility that they have. And the results emerge from self-organizing group. The Agile principles sense at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. This talks about the inspect and adapt aspects. The team evaluates the performance retrospective and comes out with ideas to improve. With this, we have reached the end of this module. In the next section, we will have a very short overview of different agile methodologies. 4. Lecture: 04 Agile Methodologies: Welcome to this module. Here we discuss different agile methodologies. This image is taken from the 12th edition of annual state of the annual report. By version one, it shows Scrums still remains as the most used agile methodology. Also, Scrum, scrum bond and Scrum XP hindbrain together make the major part of agile methodologies used. Once is Scrum. Let's start our discussion with Scrum. Let's start with a simple answer in our own words before going to the definition on the next slide. For example, Scrum is focusing on incremental iterative development. Iterations are called sprints. It depends on self-organizing, cross-functional teams, delivering a potentially shippable increment at the end of every sprint. If we go for a definition from the Scrum Guide, it stinks. Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value. Scrum is a lightweight framework, which is simple to understand but difficult to master. Scrum works with iterations or sprints of max one month duration. As we stated before, it focuses on self-managed, cross-functional teams. It ensures the continuous flow of value to customers through iterative, incremental development and delivery. It follows adaptive rather than predictive planning. It promotes collaboration among all parties involved. Scrum is one of the Agile approaches. It is the most used Agile framework. And gentle is an umbrella term for several iterative and incremental software development approaches, including Scrum. Let's discuss Kanban. Kanban is for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Each work item will pass through a series of process steps or workflow stages before it is done. Kanban means sign board, or signal. It was initially developed as a scheduling system that is used in manufacturing to help companies improve that production process. In the late 1940s, Toyota came up with a Kanban system to implement a just in time process to standardize the flow of parts in their production lines. One of the main benefits of Kanban is to establish an upper limit to the work in progress inventory, avoiding overloading of the manufacturing system. Wip limits or work in progress limits is the maximum number of work items that can be in a particular stage of processing. This will avoid the overloading of the production chain. This has been evolved into Kanban system for software development and which most people now simply referred to as kanban. Kanban is a lean approach to agile software development. It has principles and core practices. The principles are, start with the existing process, agreeing to pursue incremental and evolutionary change, respect the current process roles, responsibilities and titles, and leadership at all levels. The core practices visualize the flow, limit work-in-progress, managed flow, make policies explicit, implement feedback loops, improve collaboratively, and evolve experimentally. Lead time is the period between a new task that appears in your workflow and it's final departure from the system. This can be considered as the lifetime for an item in the system. Cycle time begins at the moment when the new arrival enters the in-progress stage and somebody is actually working on until it finishes. This will show the processing time Tok for an item. Response time is the period between a new task appears in your workflow and enters the in-progress stage. This shows how much time an item had waited in the system before the work started on it. Throughput is the number of work items delivered in a given period of time. It shows the number of items processed by the system. Differences between Scrum and Kanban. We will discuss the differences between Scrum and Kanban based on various aspects like cadence, release methodology, role's key metrics, scope of work, and response to change. In Scrum, we follow regular fixed length sprints of a maximum of one month duration. In Kanban, it is a continuous flow. In Scrum we release at the end of each sprint if approved by the product owner or as decided based on different factors. That in Kanban, it is a continuous delivery. Scrum defines roles. Product owner, scrum master, and development. There are no Kanban specific roles defined. Scrum teams use velocity to measure the amount of work done by the team in a sprint. In Kanban. Key metrics or cycle time, throughput, et cetera. In Scrum, Sprint Goal is decided during the sprint planning, whereas Kanban uses a pull system in Scrum, no change to the sprint goal is recommended within the sprint, but Kanban accommodates changes with more flexibility. Scrum Bon, Scrumban is a hybrid of Scrum and Kanban. It uses the prescriptive nature of Scrum and the process improvement of kanban. It meets the needs of teams wanting to minimize the bank size of work and adopt a pull-based system. Now we will have a quick look at Extreme Programming or XP. Extreme Programming is intended to improve software quality and responsiveness to changing customer requirements. Xp is the most specific of the Agile frameworks regarding appropriate engineering practices for software development. Extreme Programming has core values of communication, simplicity, feedback, courage, and respect. Different roles defined in XP. Xp coach, Customer, Programmer, tracker, and tester. Practices of extreme programming are planning game, test-driven development, onsite customer pair programming, continuous integration, refactoring, small releases, simple design, collective code ownership, system metaphor, coding standards, and sustainable pace. We will discuss a few of them in the coming slides. Refactoring. Code. Refactoring is the process of improving code, making it easier to understand and extend. It improves readability, maintainability, extensibility, and reduces complexity. This is done when there is a scope and made. This can happen on many occasions, including not limited to when fixing bugs. Parts of code review. When we found a duplicate. When we found the code is complex or unreadable, et cetera. Test-driven development, or TDD. Test-driven development, is an approach where the developer first writes a test case that describes a new function or improvement and then create small code to pass that test and later refactor is the new code to meet the acceptable standards. The steps involved or add the tense for new functionality, run and fail. And minimum code for passing the test. Run and pass refactor to improve code and repeat the steps. There are many other methodologies under the Agile umbrella. They'll many scaling frameworks as well. But we are limiting our discussion here. 5. Outro Our Classes in SkillShare: Before we end, we would like to provide an overview of our courses. We have various courses on a variety of topics. As summary is given in the slides here. We have many causes on Agile Scrum, software testing, agile transformation, product ownership, scrum master ship, and so on. We have detailed as well, a quick starter training on Agile and Scrum. There is specific training for Agile coaches, Scrum Masters, and Scrum product owners. We have focused courses that enable you to answer questions that you may face as a Scrum master, product owner, and other roles in Scrum. We have detailed courses on software quality assurance. Please have a look at the file attached. Keep learning. Let's sprint.