Agile a la carte menu
A reference for organizations that are intellectually-honest and problem-oriented.
Because we've all been there
Table of contents
- Scrum::product backlog
- Scrum::sprint backlog
- Scrum::sprint burndown chart and release burndown chart
- Scrum::Product Owner
- Scrum::daily standup
- Scrum::Sprint Review
- Scrum::Product backlog
- Scrum::Team velocity
- Scrum::Scrum team
- Scrum:: Team structure
- XP: Testing
- XP: Listening
- XP: Values
- XP: Principles
- XP: Pair programming
- Code smells
- Acceptance Testing
- Cross-Functional Team
- Domain model
- Technical Debt
- Fail fast
- Inspect and adapt
- Product Vision
- Self Organization
- Vanity Metric
- People Management
Scrum is an iterative and incremental agile software development framework for managing product development. It enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project.
Kanban (which means signboard or billboard in Japanese) is a scheduling system for lean manufacturing and just-in-time manufacturing. One of the main benefits of kanban is to establish an upper limit to the work in progress inventory, avoiding overloading of the manufacturing system.
The waterfall model is a sequential design process. Progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.
Extreme programming (XP)
Advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. Is intended to improve software quality and responsiveness to changing customer requirements.
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
The things on the right matter, but the things on the left are more important.
In order for an agile system to be implemented successfully, the agile coach must have buy in to transformation up and down the organization. A team cannot implement agile if executives are not bought in, and executives cannot implement agile if the team is not bought in.
These tools all solve problems:
| Problem | Solution | Comment |
| Forecasting | Estimates | Many estimation systems use Fibonacci numbers (1,2,3,5,8). If an item is > 8, it is often broken down into multiple tasks. It is VERY IMPORTANT that estimates are not treated as deadlines. |
| Changing Specs | Sprints | A sprint is a get-together of people involved in a project to further a focused development of the project. Sprints typically last from one week up to three weeks, and cannot be interupted with out-of-scope work without an abnormal termination. |
| Scheduling | Sprint Planning | In scrum, sprint Planning is a meeting that marks the beginning of a sprint. The team commits to a certain amount of work, without influence from outsiders. |
| Visibility | Kanban Board | Kanban = workflow visualization tool that enables you to optimize the flow of your work |
| Feedback | Retrospective | The sprint retrospective is an important mechanism that allows a team to continuously evolve and improve throughout the life of a project. It includes three main questions/points for discussion: 1) What went well during the sprint cycle? 2) What went wrong during the sprint cycle? 3) What could we do differently to improve? |
| Specifications | Stories | Short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>. |
| Agility | Standups | A sync-ing meeting (usually daily) in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short. |
| Dependancy Management | Dependancy Mapping | Sometimes done with just a piece of string between two stories. |
A conceptual framework for undertaking software projects. Agile methods are a family of development processes, not a single approach to software development
Abnormal termination is essentially blowing up the sprint and starting a new sprint instead.
Traditional software teams give estimates in a time format: days, weeks, months.
In contrast, Agile estimation is a team sport. Everyone who builds software is involved. The product owner typically is involved but does not get to vote on estimation.
In scrum, estimation systems are called 'story points' and use Fibonacci numbers (1,2,3,5,8). If an item is > 8, it is often broken down into multiple tasks.
Estimates are relative to other work within a team. They cannot be transcribed to hours, wdays, weeks. It is VERY IMPORTANT that estimates are not treated as deadlines.
And ideal feature is that a team learns from past estimates.
The product backlog is another artifact of Scrum. This is the complete list of the functionality that remains to be added to the product. The product owner prioritizes the backlog so the team always works on the most valuable features first.
The sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality it committed to deliver during the sprint.
Scrum::sprint burndown chart and release burndown chart
Plots burn-down using effort remaining is the most effective and efficient way of using burn-down charts
The horizontal axis of the sprint burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers -- story points, ideal days, team days and so on.
The Product Owner (PO) is the member of the team responsible for defining Stories and prioritizing the Team Backlog so as to streamline the execution of program priorities.
A scrum master is the facilitator for a product development team that uses scrum, a rugby analogy for a development methodology that allows a team to self-organize and make changes quickly. The scrum master manages the process for how information is exchanged.
A good ScrumMaster shelters the team from outside distractions, allowing team members to focus maniacally during the sprint on the goal they have selected.
While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team to the right goal. The product owner does this by creating a compelling vision of the product, and then conveying that vision to the team through the product backlog.
The third and final role in Scrum project management is the Scrum team itself. Although individuals may join the team with various job titles, in Scrum, those titles are insignificant. Scrum methodology states that each person contributes in whatever way they can to complete the work of each sprint.
Each day the Scrum Master leads the team in the Daily Scrum Meeting. This meeting designed to provide status on the progress of the sprint. Each team member speaks to three questions: what did I do yesterday, what did I do today, and what impediments got in my way.
Each Sprint is followed by a Sprint review. During this review the software developed in the previous Sprint is reviewed and if necessary new backlog items are added.
Acts as a repository for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders. The requirements are listed on the backlog in priority order and maintained by the product owner.
A relative number which describes how much work the team can get done per sprint. Velocity in scrum is measured in story points / estimates.
No matter how good a Scrum team is, there is always opportunity to improve. Although a good Scrum team will be constantly looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and to find ways to improve. This occurs during the sprint retrospective.
The sprint retrospective is usually the last thing done in a sprint. Many teams will do it immediately after the sprint review. The entire team, including both the ScrumMaster and the product owner should participate. You can schedule a scrum retrospective for up to an hour, which is usually quite sufficient. However, occasionally a hot topic will arise or a team conflict will escalate and the retrospective could take significantly longer.
Although there are many ways to conduct an agile sprint retrospective, our recommendation is to conduct it as a start-stop-continue meeting. This is perhaps the simplest, but often the most effective way to conduct a retrospective. Using this approach each team member is asked to identify specific things that the team should:
- Start doing
- Stop doing
- Continue doing
From the Retrospective Prime Directive:
One of the most obvious fears people have when first trying a retrospective is that the ritual will become a negative gripe session, interspersed with blame and counter blame.
Clearly such an event will not contribute to much learning. The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive.
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.
Within the Scrum Framework all work delivered to the customer is done by dedicated Scrum Teams. A Scrum Team is a collection of individuals working together to deliver the requested and committed product increments.
To work effectively it is important for a Scrum Team that everyone within the team follows a common goal adheres the same norms and rules shows respect to each other
Scrum:: Team structure
The basic unit of development is Squad.
Chapters and guilds
Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.
- Unit tests determine whether a given feature works as intended. A programmer writes as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature.
- Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements.
Programmers must listen to what the customers need the system to do. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solve
- Assuming simplicity
- Embracing change
XP: Pair programming
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
Why pair program:
- Design quality
- Team building
Any symptom in the source code of a computer program that indicates something may by wrong
Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.
Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.
Anyone external to the team with a vested interest in the outcome of the team’s work.
Information model describing the application domain that creates a shared language between business and IT.
The obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term. Whether or not to incur technical debt is a tradeoff decision that ideally is made in a deliberate manner at the point that work occurs.
A very large user story that is eventually broken down into smaller stories.
A fail-fast system is designed to immediately report at its interface any failure or condition that is likely to lead to failure
Inspect and adapt
The idea of discovering over the course of a project emergent software requirements and ways to improve the overall performance of the team. It neatly captures the both the concept of empirical knowledge acquisition and feedback-loop-driven learning.
A product vision is a brief statement of the desired future state that would be achieved through the project initiative.
Self-organization is a property of complex adaptive systems, whereby the organization of the system emerges over time as a response to its environment.
The movement of a software product or system from development into production.
A metric that is not actionable, and exists to make us feel better or show off
Slang for someone who is interested in a project but has no responsibility for working on a task in the active iteration.
Scrum slang. Someone who is responsible for doing a task on an active iteration. It comes from the joke, “A chicken and a pig talk about breakfast. The chicken says, ‘Let’s have bacon and eggs.’ The pig replies, ‘That’s fine for you. You are just making a contribution, but I have to be fully committed.'” Pigs are actively involved in the project.
A timebox is a time period of fixed length allocated to achieve some objective. In agile development, iterations and sprints are examples of timeboxes that limit work in process and stage incremental progress. Timeboxes are often used to avoid over-investing in tasks such as estimating development tasks.
Changing existing software code in order to improve the overall design. Refactoring normally doesn’t change the observable behavior of the software; it improves its internal structure.
Kanban: Physical or virtual
Some teams prefer physical Kanban boards over virtual ones. A physical board uses sticky notes or index cards for the Kanban cards, and the board is drawn on a whiteboard or wall.
- Scaling Agile * Spotify
Goal setting: Sticky Note Game
Here's a blog post explaining it http://www.tablexi.com/developers/xi-to-eye-the-sticky-note-game/, but TLDR is
STEP 0 Schedule * 1 employee * 1 manager * 1 or 2 advocates for employee (employee choses them) We bring lots of sharpies + sticky notes. Sponsors get diff colored sticky notes than Employee. STEP 1 We Start by just asking "What does success look like in the next 6 months for you?" It's totally open ended, that could mean anything: Community related Project related Skill related Work life balance related STEP 2 Then we put the sticky notes on the board and talk through them. 1. Which are top priority? 2. What are specific action items SOON you could take to reach them? STEP 3 Take notes into medium you decide upon: a google doc, trello, pivotal tracker, etc. STEP 4 Optional: Follow up between advocate and employee a few weeks later
One on ones
1:1s are about people & their happiness, not product management. Some assorted links: