Now that you've learned the theory of Agile, in this lesson we'll talk about how it's actually implemented. If you recall from the previous lesson, some key components of Agile are:
Two of the most common implementations of Agile, though obviously there are many flavors out there, are XP and SCRUM. XP tends to focus on how the code is produced, while SCRUM is all about managing the project itself.
Extreme was pioneered by Kent Beck during his work on the Chrysler Comprehensive Compensation System project in the late 1990s (note that it predates the Agile Manifesto). Kent basically took many of the best practices of software development at the time and told his teams to take them to the extreme and leave the rest out.
XP provides a disciplined framework for teams to focus on producing code. It worries less about the overall project management and more about how to make developers more productive.
XP says you should:
You'll learn a bit more about XP when we talk about SCRUM below. See the Resources tab if you want to dive deeper.
In Rugby, the SCRUM is the competitive huddle when play is about to be restarted. It's also a very popular agile framework that provides both project management and an actual development process (unlike XP, which is more development focused). The software folks adopted the analogy because they like holding brief check-ins to see what needs to be done that particular day.
We'll cover the high-level stuff here and the reading and videos below will fill in the details.
SCRUM project management is all about organizing the development of the User Stories we mentioned above in the section on XP.
Each project starts with figuring out the overall scope of what's needed and the high-level design of how it'll get done (the Planning phase). All the required work is broken into user stories, prioritized, and placed into the Product Backlog. The backlog is broken up into short iterations (1-4 weeks) called Sprints, where the goal of each is to finish a certain number of items in the backlog. Ideally, finishing a sprint will result in some discrete or deployable product.
When a sprint begins, everyone gets on the same page about what items from the backlog they need to tackle during that sprint. During a sprint, every day begins with the SCRUM meeting where each member of the team very briefly highlights:
Team members stand for the whole meeting to keep it short. One member is assigned the role of the SCRUM Master and takes charge of the process. Another, called the Product Owner, advocates on behalf of the user and may be the client, a real user, or the Product Manager of the team.
The product backlog is populated by the same user stories we mentioned above. Each story is assigned a certain number of points related to its complexity. To see how much progress they are making during the sprint, the team uses a burndown chart which shows how many points they have finished relative to how many points they have left.
After the sprint ends, there is a Retrospective meeting with the entire team and the client to figure out how it went and what they learned. The team then takes a look at the backlog and decides what needs to be removed, added, or re-prioritized.
Once the client decides enough features have been built to release the product, the development team stops doing sprints and does testing, training, and documentation as necessary to make the release happen.
Source: Sathees Kumar
SCRUM's development is closely tied with the project management: small teams are allocated to each backlog item being worked on in the current sprint. The team working on a backlog item is responsible for writing the code, testing it, documenting it, and demonstrating it upon completion.
SCRUM teams often also use practices associated with XP like pair programming and continuous integration.
Start by watching this video (below) about SCRUM, which focuses on the business value it generates:
Then watch this video (below) for a more detailed look at how it's implemented:
You should have a good overview of the philosophy of XP and a more detailed understanding of how SCRUM looks. You don't necessarily need to remember all the steps that are involved, but you should have a general picture in your head about how a SCRUM project comes together and how you might fit into it.
This is useful stuff because you might be a part of a SCRUM team as a software engineer working for a firm, or you might actually implement it yourself to help manage your development process as an entrepreneur.
In the next lesson, we'll dive deeper into user stories since they will be used extensively throughout the mini-courses, the main VCS program, and your development career. They also help tie together the philosophy of User-Centered Design with the development of those designs, which is great because we're pretty sure hundreds of puppies around the world get a little bit cuter whenever Design and Development come together like that!
Source: Global Nerdy