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.
{% hyf-youtube src="https://www.youtube.com/watch?v=Z9QbYZh1YXY" %}
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.
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.
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 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.
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".
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.
When you’re building software, it’s not always easy to see the direct connection between the agile values and the day-to-day work. That’s where the principles behind the Agile Manifesto come in.
1- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Early delivery + Continuous delivery = Satisfied users
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.
3- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
If the team is building a feature that isn’t useful or does the wrong thing, the users will spot it early, and the team can make the change before too much code is written... and preventing rework prevents bugs.
4- Business people and developers must work together daily throughout the project.
It’s really common for developers to dread or resent meeting with users, because those meetings often uncover changes, which leads to rework that can often be difficult and frustrating. But when the team has a better, more agile mindset, they know that meeting with users more often keeps them in sync, and actually prevents those changes.
5- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
When the team gets together and talks about what they need to build, it really is the most efficient and effective way to communicate exactly what needs to be built... and also status, ideas, and any other information
7- Working software is the primary measure of progress.
8- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9- Continuous attention to technical excellence and good design enhances agility.
10- Simplicity—the art of maximizing the amount of work not done— is essential.
11- The best architectures, requirements, and designs emerge from self-organizing teams.
12- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
{% hyf-youtube src="https://www.youtube.com/watch?v=m5u0P1WPfvs" %}
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.
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)
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.
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.
If you just can't get enough, here are some extra links that mentors/students have found useful concerning this topic: