Update agile.md

Added video's and reorganised it

software-development/agile.md

@@ -1,119 +1,31 @@
 # Agile
 
-- [References](#references)
+Agile is a broad term that is used for many different things, meaning that whenever someone talks about being 'agile' it could mean different things. In this article we will identify the main concepts behind it, but in your discussions with other teams being agile / scrum gets used interchangeably and will mean different things to different people.
 
----
 ## What is Agile ?
 
-1- **Agile is a set of methods and methodologies :**
-
-Agile is a set of methods and methodologies that are optimized (improved) to help with specific problems
- that software teams run into and keep everything simple so they are relatively easy to implement(execute).
-These methods and methodologies address all of the areas of traditional software engineering,
-including project management, software design and architecture, and process improvement. Each of 
-those methods and methodologies  consists of practices that are streamlined and optimized to make
-them as easy as possible to adopt.
-
-2- **Agile is also a mindset :**
-
- The agile mindset is focused on helping people share information with each other, which makes it 
- much easier for them to make important project decisions (rather than just relying on a boss or 
- project manager to make those decisions). It’s about opening up planning, design, and process 
- improvement to the entire team. To help everyone get into an effective mindset, each agile methodology 
- has its own set of values that team members can use as a guide.
-
-For the first time, Agile team has found a real, sustainable way to solve problems that generations of
- software development teams have been struggling with. Agile teams use simple, straightforward practices
- that have been proven to work on real-life projects. **But wait a minute...if agile is so great, why isn’t everyone doing it?**
-
-It turns out that in the real world, a practice that works really well for one team causes serious problems for another team, and
-**the difference is the team mindset**. So get ready to **change the way you think about your projects.**
-
-**A daily standup is a good starting point**
-
-One of the most common agile practices that teams adopt is called **the daily standup**, a meeting
- that happens every day, during which team members talk about what they’re working on and their challenges.
- The meeting is kept short by making everyone stand for the duration. Adding a daily standup to their projects
- has brought success to a lot of teams, and it’s often **the first step in going agile.** The daily standup meeting
- is much more effective when everyone on the team has the right mindset—everyone listens to each other, and they all
- work together to make sure the project is on track.
-
-**A better mindset makes the practice work better**
-
-Now that the daily standup is in place, the whole team works together every day to find the best approach to 
-the project more efficiently! and make sure everyone is making solid decisions, and that the project is on track.
-
-## Agile approaches 
----
-a- **Scrum is the most common approach to agile**
-
-**Scrum** is a software development framework focused on project management and product development.
-When a team uses Scrum, every project follows the same basic pattern. There are three main roles on a Scrum project : 
+{% hyf-youtube src="https://www.youtube.com/watch?v=Z9QbYZh1YXY" %}
 
-1- **Product Owner** works with the team to maintain a Product Backlog (a list of the new features, changes to existing
-features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.)
-
-2- **The Scrum Master** helps guide the team past roadblocks 
-
-3- **Development Team members** (everyone else on the team)
-
- The project is divided into sprints (two weeks to one month). At the start of a sprint, the team does **sprint planning** to determine which features from the **Product Backlog** they’ll build during the sprint. This is called the **Sprint Backlog**, and the team works throughout the sprint to build all of the features in it. Every day the team holds a short meeting called the **Daily Scrum**. At the end of the sprint, working software is demonstrated to the product owner and stakeholders in the **sprint review** , and the team holds a **retrospective** (A retrospective is a meeting in which everyone talks about how the last part of the project went) to figure out lessons they’ve learned.
-
-
-
-b- **XP and Lean/ Kanban**
-
-The next most popular methodology is **XP**, a methodology focused on software development and programming that’s often used in combination with Scrum. Other teams approach agile with **Lean and Kanban**, a mindset that gives you tools to understand the way you build software today and a method that helps you evolve to a better state tomorrow. 
-
----
-**Question** : It sounds like Scrum, XP, and Lean/ Kanban are very different from each other. How can they all be agile?
-
-Scrum, XP, and Lean/Kanban focus on  very different areas.
-
- **Scrum** is mainly focused on project management: what work is getting done, and making sure that it’s in line with what the users and stakeholders need.
-
- **XP** is focused on software development: building high-quality code that’s well-designed and easy to maintain.
-
-**Lean/Kanban** is a combination of the Lean mindset and the Kanban method, and teams use it to focus on continually improving the way that they build software.
-
-In other words, **Scrum, XP, and Lean/Kanban** are focused on three different areas of software engineering: **project management, design and architecture, and process improvement**. So it makes sense that they would have different practices—that’s how they differ.
-
----
-
-## Agile values and principles 
-
-### Agile values
-
-**Agile Manifesto** : it is the four values of Agile to guide the team to a better, more effective mindset. The Agile Manifesto contains four X over Y lines that help us understand what
-agile teams value. Each of those lines tells us something specific about the values that drive an agile mindset. We can use them to help us understand what it means for a team to be agile.**The four values in the Agile Manifesto are equally important, so there’s no particular order for them. Just make sure that each specific value (X over Y) is matched up.**
+### Agile values / manifesto
 
 1- **Individuals and interactions** over processes and tools : 
 
-Agile teams recognize that processes and tools are important to getting the project done, and they can be really valuable. You’ve already learned about a few practices that agile teams use: daily standups, user stories, task boards, and retrospectives. These are all valuable tools that can make a real difference to an agile team.
-But agile teams value individuals and interactions even more than processes and tools, because **teams always work best when you pay attention to the human element . the individual people on the team are  more important**.
+Agile teams recognize that processes and tools are important to getting the project done, and they can be really valuable. You’ve already learned about a few practices that agile teams use: daily standups, user stories, task boards, and retrospectives. These are all valuable tools that can make a real difference to an agile team. But agile teams value individuals and interactions even more than processes and tools, because **teams always work best when you pay attention to the human element, the individual people on the team are more important**.
 
 2- **Working software** over comprehensive documentation
 
-What does “working” software mean? How do you know if your software works? That’s actually a harder question to answer than you might think. A traditional waterfall team (traditional way of building software, where the team first defines strict requirements, then draws up a complete design, and builds out all of the software architecture on paper before the code is written. )  starts a project by building comprehensive requirements documents to determine what the team will build, reviews that documentation with the users and stakeholders, and then passes it on to the developers to build.The problem with documentation is that two people can read the same page and come away with two very different interpretations. That’s why **agile teams value working software over comprehensive documentation—because it turns out that the most effective way for a user to gauge (
-measure) how well the software works is to actually by use it**.
+What does “working” software mean? How do you know if your software works? That’s actually a harder question to answer than you might think. A traditional waterfall team (traditional way of building software, where the team first defines strict requirements, then draws up a complete design, and builds out all of the software architecture on paper before the code is written. ) starts a project by building comprehensive requirements documents to determine what the team will build, reviews that documentation with the users and stakeholders, and then passes it on to the developers to build. The problem with documentation is that two people can read the same page and come away with two very different interpretations. That’s why **agile teams value working software over comprehensive documentation—because it turns out that the most effective way for a user to gauge (measure) how well the software works is to actually by use it**.
 
 3- **Customer collaboration** over contract negotiation
 
-Agile teams value customer collaboration over contract negotiation (strict agreement on what the team will build or do before any work can start). They recognize that projects change, and that people never have perfect information when starting a project. So instead of trying to nail down exactly what’s going to be built before they start, they collaborate with their users to try to get the best results. **Scrum teams** are especially good at this because they have a **product owner** who is a true member of the team. He/She  might not have been developing code, but He/She  worked hard on the project by talking to users, understanding what they needed, and working with the rest of the team to help them understand those needs and build working software.
+Agile teams value customer collaboration over contract negotiation (strict agreement on what the team will build or do before any work can start). They recognize that projects change, and that people never have perfect information when starting a project. So instead of trying to nail down exactly what’s going to be built before they start, they collaborate with their users to try to get the best results. **Scrum teams** are especially good at this because they have a **product owner** who is a true member of the team. He/She might not have been developing code, but He/She worked hard on the project by talking to users, understanding what they needed, and working with the rest of the team to help them understand those needs and build working software that solves the actual problems of the user.
 
 4- **Responding to change** over following a plan
 
 Some project managers have a saying: “Plan the work, work the plan.” And agile teams recognize that planning is important. But working a plan that has problems will cause the team to build a product with problems.The problem with plans is that they’re built at the start of projects, and that’s when the team knows the least about the product they’re going to build. So **agile teams expect that their plans will change**.
 
-**It’s important to plan your project, but it’s even more important to recognize that those plans will change once the team starts working on the code.**
 **In agile projects, your product is developed step by step, each new step drawing knowledge from the previous step. When a plan (or requirement, or anything else you use in a project) is developed this way, it’s called "progressive elaboration".**
 
----
-**Question** : I’m still not clear on what  “waterfall” means ?
-
-Waterfall” is the name given to a
-specific way that software companies have traditionally built software. They divide their projects into phases, usually drawn in a diagram. The team is often expected to come up with a nearperfect requirements document and design before they start building code, because it takes a lot of time and effort to go back and fix the requirements and design when the team finds problems with them.**The problem is that there’s often no way to know if the requirements and design are right until the team starts building code**.
-
 ### Agile principles
 
 The **four values in the Agile Manifesto** do a really good job of capturing the core of the agile mindset. But while those four values are great at giving you a high-level understanding of what it means to “think agile,” **there are a lot of day-to-day decisions that every software team needs to make**. So in addition to the four values, **there are twelve principles behind the Agile Manifesto** that are there to help you really understand the agile mindset.
@@ -124,7 +36,7 @@ When you’re building software, it’s not always easy to see the direct connec
 
 Early delivery +  Continuous delivery  =  Satisfied users
 
-2- **Welcome changing** requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
+2- **Welcome changing requirements**, even late in development. Agile processes harness change for the customer’s competitive advantage.
 
 When the team delivers software early and often to the users, stakeholders, and customers, that gives everyone lots of chances to find changes early, when they’re much easier to make.
 
@@ -155,35 +67,36 @@ When the team gets together and talks about what they need to build, it really i
 
 12- At regular intervals, the team reflects on how to become more effective, then **tunes and adjusts its behavior** accordingly.
 
----
-
-**Question** : The first three principles behind the Agile Manifesto talk about early and continuous delivery of software, welcoming changing requirements, and delivering working software on a short timescale. So **how do teams do that in the real world**?
+## Scrum
 
-With great practices, like 
+{% hyf-youtube src="https://www.youtube.com/watch?v=m5u0P1WPfvs" %}
 
-- iteration :  repeatedly performing all of the project activities to continuously deliver working software and 
-- backlog : is a list of features waiting to be built. Any feature that hasn’t been included in an iteration yet is fair game for the users and the product owner to change.
+**Scrum** is a software development framework focused on project management and product development based on the Agile principles. When a team uses Scrum, every project follows the same basic pattern.
 
-**Question** : We learned about how Scrum teams use a backlog earlier. Does that mean Scrum sprints are a form of iteration?
-
-Yes! Scrum uses an **iterative approach**. The Scrum practice of using sprints is a classic example of how teams use iteration in real life to deliver working software early and frequently. The Scrum team has a **Product Owner** who works with the users and stakeholders to understand their needs. Everyone learns more with each new version of the working software, and the Product Owner uses that new knowledge to add or remove features from the backlog.
+### Roles
+1- **Product Owner** works with the team to maintain a Product Backlog (a list of the new features, changes to existing
+features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.)
 
+2- **The Scrum Master** helps guide the team past roadblocks 
 
----
-Reference :
+3- **Development Team members** (everyone else on the team)
 
-Stellman, A. & Greene,J (2017) Head First Agile A Brain-Friendly Guide.O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.P 1-68
+### Daily scrum / standup
+One of the most common scrum practices that teams adopt is called the daily standup, a meeting that happens every day, during which team members talk about what they’re working on and the challenges they are facing. The meeting is kept short by making everyone stand for the duration. Adding a daily standup to their projects has brought success to a lot of teams, and it’s often the first step in going agile. The daily standup meeting is much more effective when everyone on the team has the right mindset—everyone listens to each other, and they all work together to make sure the project is on track.
 
----
+### Sprints
+Scrum defines a teams time into sprints of 2-4 weeks. At the start of a sprint, the team does a **sprint planning** to determine which features from the **Product Backlog** they’ll build during the sprint. This is called the **Sprint Backlog**, and the team works throughout the sprint to build all of the features in it. Every day the team holds a short meeting called the **Daily Scrum** as mentioned above. At the end of the sprint, working software is demonstrated to the product owner and stakeholders in the **sprint review** , and the team holds a **retrospective** (A retrospective is a meeting in which everyone talks about how the last part of the project went) to figure out lessons they’ve learned and make changes to perform better.
 
-## References
+# Extra reading
+If you just can't get enough, here are some extra links that mentors/students have found useful concerning this topic:
 
+* [What is Agile?](https://www.cprime.com/resources/what-is-agile-what-is-scrum/)
 * [Agile Manifesto](https://agilemanifesto.org/principles.html)
 * [Agile Development by Cartoon](https://www.youtube.com/watch?v=Z9QbYZh1YXY&list=PLBUu5aGDLKnbeEx8U-5r436bw6p9wv1rS)
 * [Splitting User Stories](https://www.youtube.com/watch?v=EDT0HMtDwYI)
 * [user story based portfolio example](https://github.com/elewa-student/User-Centered-Development)
 
-### User Stories
+## User Stories
 
 * [Agile Development by Cartoon](https://www.youtube.com/watch?v=Z9QbYZh1YXY&list=PLBUu5aGDLKnbeEx8U-5r436bw6p9wv1rS)
 * [Splitting User Stories](https://www.youtube.com/watch?v=EDT0HMtDwYI)