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.
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 :
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 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.
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.
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.
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.
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?
With great practices, like
- 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.
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.
Reference :
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
- Agile Manifesto
- Agile Development by Cartoon
- Splitting User Stories
- user story based portfolio example
- Head First Agile A brain-friendly Guide (+1, pdf)
- Agile Software Development (pdf)