- List the core values of agile software development
- Describe how agile development is different from waterfall
- Explain the core concepts of all agile software development
- Describe common types of agile development (scrum, kanban, XP, lean) and their roles
- Explain the purpose of common ceremonies used by agile teams (IPM, Sprint Planning, Retro)
Can you think of an app or software you've used that's changed / improved over time?
What we call the 'agile' software movement started back in 2001, when a bunch of software developers met up and talked about how there must be a better way of building software. Most of them were working in places where waterfall was the way of working, and that was painful for them.
They agreed on 4 values, which is referred to as 'the agile manifesto'.
- Individuals & Interactions over Processes & Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation
- Responding to Change over Following a Plan
Ask students to talk in pairs about what these might mean in software development
While the agile manifesto was really important, and helped popularize modern ways of building software there are a few things we should keep in mind as we talk about agile:
- Agile wasn't the very beginning, lots of people were thinking about better ways of building software before 2001
- The manifesto is a set of values, but it doesn't tell you how to actually work
- There's never one "best" way to work, it always depends on a lot of factors
Both waterfall and agile methodologies describe ways to build software, and both acknowledge that software will change, but the core difference is that agile embraces that change. Instead of trying to get everything right the first time, agile encourages you or a team to try things, see what happens, learn, and change course based on what you learned.
In agile, you don't try to define all your requirements and features up front, instead you find a good place to start, build something as small as you can, as quick as you can, then then release it for people to use.
Similarly, as you're building, you don't try to plan for every feature, and document that plan / design / architecture. Instead, you try to do the simplest thing that works, and change your design as you go. The code and the software are the most important 'documentation'. (Written docs get out of date).
Agile encourages the development team to work closely with the customers (stakeholders) and users, to do what's best for the project, compared to waterfall, which is less flexible and suggests you stick to your original plan / requirements.
The user story is the main way that software teams describe the work that needs to get done in building the software (the features).
Here's an example:
As a shopper,
I want to add an item to my cart,
so I can keep track of the items I am about to purchase.
As an inventory manager,
I want to mark an item as sold out,
So I can ensure we don't sell items we don't have in stock.
As a shopper,
I want to see the 'Add to Cart' button disabled if an item is sold out,
So I know that I can't accidentally add it to my cart.
In most agile teams, stories also include more detailed 'acceptance criteria' that define in more detail how someone can use the software to check and see if the feature has been built correctly.
Each time developers finish a feature, they'll pick up the next story and read it so they know what they need to do.
Stories are great, but they aren't perfect. Good teams demonstrate the agile value of people and interactions by talking to each other about stories. We want to make sure everyone understands what the story really means, and why it's important. Sometimes we realize there's a better way to solve the underlying problem (perhaps a smaller feature will get the job done).
Agile encourages you to do small batches of work, sometimes called sprints or iterations. At the end of these iterations, you should have fully working software that you can demo or release as an update for your users to use.
For example, if the basic flow of a shopping app is search -> add to cart -> checkout, we shouldn't do all the search features first, then do all the cart features, then the checkout. We want to start with a basic search, basic cart, and basic checkout, so the users can actually buy stuff as quickly as possible.
Then, in the next iterations, we can add more features to one or more of those areas.
There are many 'methodologies', or pre-defined ways to work in an agile way. Lots of people will try to sell certifications for, or teach companies how to do a specific methodology, but there is not really any best way. Different methodologies work better at different times, or for different teams, and sometimes it's best to modify, adapt, or remix parts of these methodologies.
Scrum is one of the first 'complete' methodologies for doing agile, it started in the 90s and the main book describing it came out in 2001.
Scrum centers around the concept of sprints, which are 2-4 week time periods where the team plans and agrees on what they want to get done during the sprint. This happens at a sprint planning meeting where the team talks about what they can commit to finishing in the sprint. They also estimate how big each story is.
Each day during the sprint, the team has a standup (scrum) to talk about the work they are doing and how it's going.
At the end of each sprint, the team does a demo for stakeholders and/or users.
Question: What might it mean if the stakeholders are surprised or unhappy when a team demos the software?
Also at the end of the sprint (after the demo), the team will hold a retrospective ('retro'), to talk about what went well, and what could have gone better, and ideally what actions the team can take to improve things.
- Scrum Master - Enforces the process, protects the team from distractions, and resolves blockers.
- Product Owner - Manages the backlog and writes stories.
- Development Team - Build the software
XP is a much more opinionated flavor of agile, especially when it comes to how people actually write code.
It uses stories, but instead of sprints where the team commits to getting work done, it uses iterations where the work can always change in the middle as the team learns and or reprioritizes the work.
- Simplicity
- Feedback
- Communication
- Respect
- Courage
For writing code:
- Pair Programming
- TDD
- Simplest Thing
Other:
- Sit together
- Informative workspace
- Whole team participates
Kanban isn't a full methodology like Scrum or XP, but rather a small set of principles about limiting how much work you are doing at a time (called work in progress or WIP).
In Kanban, you model the steps of your process, and limit the amount of items that can be active in each step. (e.g. building, testing, reviewing, deploying, done).
Essentially, Lean Startup is about applying the scientific method to new ideas. In the first step (01), you formulate your hypothesis. I strongly recommend doing this with validated problem scenarios so you make sure you’re proposition is relevant to a job or habit that actually exists for your customer.
In the second step (02), you declare your hypotheses (or assumptions) in a testable format, usually, ‘If we do [something] for [segment or persona], then they will [respond in a certain, measurable way].’ In the third step (03), you design experiments to test the hypotheses—the best ones take a week or less. Then you execute those experiments (04) and evaluate your results (05). If your results were above your target threshold, ‘persevere’ (6b) and scale up the idea. If they don’t, ‘pivot’ (6a) and try something else before you waste your resources on a proposition the customer/user doesn’t want.
UCD is the practice of ensuring the needs of the user are front-and-center to all the work that a team does. In UCD, a designer is responsible for talking to users, building prototypes, and testing them with users. They take what they learn and use it to improve the design of the software before developers go and build it, which is the most expensive part of software development.