Agile for the Real World

1. Agile in the Real World (4 min)
This Nugget kicks off our Agile in the Real World course and provides an overview of the Agile principles and techniques which will be covered in the course.
2. Agile Manifesto (11 min)
This Nugget reviews the foundation document for Agile, the Agile Manifesto created in 2001. The Agile Manifesto presents four fundamental approaches for delivering software projects in Agile fashion. Next, the Nugget reviews the 12 Agile principles and concludes with a review of the Declaration of Interdependence. These three documents lay the foundation for being Agile, and for this Nugget course.
3. Agile vs. Scrum vs. Kanban (6 min)
This Nugget reviews and contrasts the various Agile development techniques focusing specifically on Agile, Scrum, and Kanban. While each method has its own characteristics, this course will use a combination of all these methods to develop the real-world conference scheduling system.
4. Product Vision (6 min)
This Nugget reviews what a project vision should contain and presents the project vision for the real world project.
5. Product Owner (4 min)
This Nugget reviews the role of the Product Owner in an Agile project. The Product Owner is the business resource who is responsible for defining what the project is to accomplish. Therefore, the Product Owner is the most important person on the project and must have adequate time available to support the project team.
6. Scrum Master (6 min)
This Nugget reviews the role of the Scrum Master (or Agile Master) in an Agile project. The Scrum Master is an experienced Agile delivery person who is responsible for ensuring that the project is following Agile/Scrum principles. While the Scrum Master position is optional, it is highly recommended for all, but the most experienced Agile teams to ensure that a seasoned individual is tasked with guiding and directing the team and the project to a successful conclusion using proven Agile approaches.
7. Agile Team Member (5 min)
This Nugget reviews the role of the Team Member in an Agile project. The Team Member is a member of a self-organizing team who must be prepared to do all the work required to move a story through analysis, design, coding, and testing to ensure it is complete and ready for implementation. An Agile Team Member must be prepared to fully participate in all project activities, while at the same time ensuring that a minimalist approach is taken to ensure that the work required to complete each story is completed.
8. Minimal Marketable Feature (6 min)
This Nugget focuses on a key Agile concept called Minimal Marketable Feature, which defines that the business (and the project) should focus on ensuring that only the functionality required to support “today’s business requirements” are completed, and that no embellishment or future considerations are undertaken by the project.
9. Simple Design (6 min)
This Nugget reviews the principle of Simple Design to ensure that the Agile team designs (and therefore builds) the code that will satisfy just the requirements for each story and that no future considerations are built. YAGNI (You Aren’t Going to Need It) embodies Simple Design and defines that no future data elements or extendible database tables are built on the expectation that at some point in the future they may be required.
10. Stories and Epics (8 min)
This Nugget reviews the creation of the Stories and Epics for an Agile project. Epics represent the high-level business functions that are to be delivered by the project. Stories are the lower level decomposition of the Epics into discrete code development units.
11. Definition of Done (2 min)
This Nugget reviews the next segment of the Story Card, which is the Definition of Done. The Definition of Done defines the criteria that the business users will apply to validate that the story satisfies their requirements. The Definition of Done is used to develop the test cases that will be used to validate the code functionality.
12. Story Conversations (5 min)
This Nugget reviews a critical aspect of Story development, which is team members having conversations with the business to better understand the requirements for each story. These conversations allow the team to clarify and better understand both the requirements for the story, as well as validate the business’s expectations for the Definition of Done. While these conversations are casual and adhoc, the results should be documented to ensure that these clarifications are preserved.
13. Story Point Estimating (8 min)
This Nugget reviews the processes to be followed to develop the estimate for the level of effort required to develop and test each story. Stories are estimated in Story Points, which define the relative magnitude of the work required and is typically prepared as a comparison to other stories, i.e. this is twice as big as a previous story. Various relative sizing techniques such as Fibonacci and Power of 2 estimate are reviewed as well as methods for reaching team consensus such as Planning Poker, Fists of 5, or Estimating Game.
14. Product Backlog (5 min)
This Nugget reviews the Product Backlog and how it is used to manage the stories to be developed in the Project. The Product Backlog is a corkboard divided into segments and priorities to allow the Product Owner to manage the stories by moving and refining them to appropriate segment.
15. Release Roadmap (5 min)
This Nugget reviews the creation and use of the Release Roadmap. The Release Roadmap is an upfront planning document which is used to provide overall direction to the project by defining the order and timing of the releases which will make up the project. A release is defined as the combination of the results of several development iterations and is the actual implementation of the code into the organization’s production environment.
16. Release Plan (5 min)
This Nugget reviews the creation of the Release Plan, which is a short-term plan to define the sprints and stories to be included in the current release. The Release Plan provides the vision for the work done in the release and helps ensure that no unrelated work is taken on.
17. Backlog Grooming (7 min)
This Nugget reviews the processes associated with Backlog Grooming, or as it is sometimes called Story Time. Backlog Grooming is primarily the responsibility of the Product Owner, but other business users can participate to help define the story and the team is involved to develop the story point estimates. During Backlog Grooming, the Story Card is updated to record the updates to the story description, definition of done, story point estimates and priority. The Story Card is also moved around on the Product Backlog to reflect its current status and priority.
18. Sprint Planning (9 min)
In this Nugget, we review the process for identifying the stories which will be completed in the next sprint. The Product Backlog is the key input to sprint planning and involves selecting the highest priority stories, while ensuring that the story point count of the selected stories does not exceed the project’s capacity or velocity. This often involves a degree of re-planning to ensure that the appropriate stories are selected for development in the sprint satisfying product owner priorities, story point estimates, and natural precedence for the completion of stories.
19. Burn Down Chart (6 min)
This Nugget reviews the development of the sprint Burn Down Chart. The Burn Down chart is one of the more well known sprint reports and tracks the completion of the individual stories over the duration of the sprint. It is a simple graph with time as the x-axis and story count as the y-axis. On a daily basis, the number of stories are tracked and graphed to report on the sprint progress.
20. Rhythm (8 min)
This Nugget reviews why Rhythm is important to successful Agile delivery. Rhythm is based on establishing the team’s capacity and then adhering to this to ensure that the team is able to complete the assigned stories in a repeatable and predictable fashion. Rhythm is important in Agile as the team must perform consistently across the many sprints required to complete the project.
21. A Sprint (11 min)
This Nugget reviews the six components of a sprint: Sprint Plan Part 1, Sprint Plan Part 2, Complete/Develop the stories, Track Progress, Sprint Review, and Sprint Retrospective.
22. Self Organizing Team (5 min)
This Nugget reviews a key Agile principle that the team is a self-organizing, self-managing team of equals, or in other words, that the team is self organizing. While an Agile project may have a Scrum Master, this role is a mentor and guide, not a project manager. It is the team’s responsibility to manage itself. Another principle consistent with self organizing that is also reviewed in this Nugget is the lack of code ownership. As any team member can complete any story, they as a result, can modify an existing code component previously made by another team member — which is the reason that lack of code ownership is important in Agile.
23. Daily Scrum (5 min)
This Nugget discusses the Daily Scrum or as it is often called the Daily Standup. This is a mandatory team meeting held daily at a consistent time and place, and is a round table where each team member discusses what they worked on the past day, what their plans are for the next day, and any problems and impediments. The goal is to quickly ensure everyone on the project is up to date and to formulate the necessary next steps to keep the activity on the sprint moving forward.
24. Information Radiators (7 min)
This Nugget focuses on the most common information radiators (status reports) used by Agile projects. These include the product, release and sprint visions, product backlog, burn down chart and any other key visual indicator of how the project is doing. The visibility factor is why these are called information radiators, not simply status reports.
25. Closing a Sprint (7 min)
This Nugget reviews the activities associated with closing a sprint, as well as what to do when the team can’t complete all the stories assigned to the sprint or when then team actually does complete all the stories prior to the end of the sprint.
26. Tracking Velocity (7 min)
This Nugget reviews the processes the team must follow to ensure that the velocity accurately reflects the capacity of the team to complete a specified number of story points in a sprint. This includes a review of tracking the actual stories completed by sprint and then adjusting the velocity when a trend indicates that a change is necessary. The Nugget also reviews the importance of validating the story point estimates to ensure that the velocity is being calculated using realistic story point estimates.
27. Retrospectives (5 min)
This Nugget reviews how to ensure that retrospectives add value to an Agile project. The key message is that the retrospective needs to be done at the end of each sprint to ensure continuous process improvement. A retrospective board is presented as one method for completing these important end-of-sprint activities which improve productivity, decrease errors, improve quality, and increase velocity.
28. Adjusting a Sprint (6 min)
This Nugget reviews when it is appropriate to change an in-flight sprint. While the Nugget begins with a statement that whenever possible an in-flight sprint should not be changed as it destroys the team’s rhythm and velocity, it does recognize that there will be valid reasons for making some changes based on the amount of work the team can do. Also, because a sprint is only two weeks-long, it provides the team with justification for postponing the change until the end of the sprint to ensure that the change is well thought out and fully defined.
29. Continuous Integration (6 min)
In this Nugget, we begin a review of the technical aspects of Agile development and review the principle of continuous integration, which means every time a piece of code is checked in, an automated build and test progress is kicked off to ensure that the new code works — and more importantly that the new code didn’t break any existing functionality. Continuous integration is a fundamental component of Agile as it allows a team to update existing code with the requirements of each new story with confidence that they will not be breaking anything, or if they do, they will be immediately notified of the issue.
30. Build Automation (6 min)
In this Nugget, we review what is involved in build automation, namely an integrated technical environment that connects the code management repository with the build server and the test server to facilitate a build and test sequence for every check in. The Nugget also reviews how you can still be Agile with one or more of the technical components of build automation that are not in place within your organization.
31. Incremental Development (6 min)
In this Nugget, we review how each new story will incrementally build on existing code to eventually develop the full functionality required by the business. The Nugget presents a sample of a piece of code, and the associated database, and follows how each new story adds new code and expands the database definition.
32. Pair Programming (7 min)
In this Nugget, we review the Agile development technique of pair programming, which is having two developers work on a single piece of code. One codes and the other desk-checks the work and things ahead to the next step or how to test the code being written, and then the roles are switched. To help you make the decision whether pair programming will work on your project, the Nugget also reviews pros and cons of using this technique.
33. Test Driven Development (5 min)
This Nugget reviews another Agile development technique called Test Driven Development. Test Driven Development defines an approach where all test cases are developed first and inputed into the testing tool and then, and only then, does the development of the code begin. Once enough code bas been written to satisfy all the test cases, the coding process is complete, based on the premises that the test cases support the story card and the code satisfies the test cases.
34. Spikes (8 min)
This Nugget explores an Agile development technique called spikes. A spike is needed whenever the team needs time to test or validate the best way to work. When a requirement is identified to do some exploration, the team writes a team story and adds it to the product backlog for inclusion in the next sprint. Once the product owner includes the spike in a sprint, the team has the time needed to write to code to address their concerns and find the best solution.
35. Technology Debt (4 min)
This Nugget reviews the Agile development technique called technology debt. Technology Debt is what happens as the result of incremental development where the combination of new code from multiple stories over time results in less than perfect code. When this happens, the team writes a team story and puts it on the product backlog to get the time needed to remove the “code smells” and restore the code to a well-structured module.
36. Caves and Commons (5 min)
This Nugget reviews a recommended work space configuration for Agile teams called caves and commons. The team is expected to spend most of their time in the “commons” which is a public area where everyone has a desk, but no dividers. The purpose of the commons is to facilitate interaction between the team.
37. Kanban Board (9 min)
This Nugget reviews a workflow management process called the Kanban Board. The Kanban Board defines all the steps in the development of a story, and also defines the limit of the number of stories that can be in each process step. Limiting the stories in a step ensures that the team remains focused on doing the right things at the right time to help ensure all stories are completed within the sprint.
38. Documentation (5 min)
This Nugget reviews the type and style of documentation an Agile project needs to produce. Unlike popular opinion, an Agile project still needs to produce documentation, but not near as much as a traditional project. Agile projects should only need to document usage items such as user guides and implementation and support guides.
39. Release/Implementation (7 min)
In this Nugget, we review the work required to implement a release into production. And while most of the work associated with implementation follows a more traditional approach for testing, training, data conversion, and moving the code to production, these are still tasks that must be done during an Agile project to implement the code developed in all the sprints that make up the release.
40. Scaling Agile (8 min)
In this Nugget, we discuss how an Agile project can be scaled to complete larger and more complex projects in a realistic timeframe. Simply adding more team members is not feasible, as most Agile principles are based on self-organizing, self-managing teams that don't work with large teams. Therefore, to scale an Agile project, a principle called "Scrum of Scrums" is used where smaller sub-teams are created, which follow traditional Agile approaches and consist of a member of each team meeting in a "Scrum of Scrums" to ensure that the overall work across the sub-teams are coordinated.
41. Other Agile Methods (7 min)
This Nugget concludes this course with a brief overview of the various methods that can be followed by organizations being Agile.