Let's discuss this on my blog: http://www.sarfata.org/back-to-basics/basic-agile-practices/
My goal today was to extract the most important (IMHO) practices of agile methodologies that can be applied individually or together to improve the performance and well-being of project teams. I split those practices into two: practices for the developers, practices for the entire team.
My selection of practices included:
* Pair programming
* Collective Code Ownership
* Refactoring
* Test Driven Development
* Continuous Integration
* Standup Meeting
* Kanban (the post-it board)
* Time-boxing - Sprint
* Backlog
* Retrospective
Slides distributed under the CC-BY-SA license. As always feedback is much appreciated!
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Back To Basics: Agile Practices
1. Back to Basics Series
Topics
Intro to agile methodologies
Basic agile practices for the
Basic Agile Practices development team
Basic agile practices for the project team
Thomas Sarlandie Intended audience
Development teams and their
2013 03 27 counterpart in any company
2. Image by RelaxingMusic - Used under a CC-BY license: http://www.flickr.com/photos/83905817@N08/7676582338/
3. Agile development is not
about doing sport in the
office
Image by RelaxingMusic - Used under a CC-BY license: http://www.flickr.com/photos/83905817@N08/7676582338/
4. Agile development is not
It is about finding a better
about doing sport in the
way to work together
office
Image by RelaxingMusic - Used under a CC-BY license: http://www.flickr.com/photos/83905817@N08/7676582338/
6. Agile Software Development today
SCRUM
Focuses on project management (team and work organization) and on
planning. (Strategic level)
Extreme Programming
Practices to improve efficiency of development teams. (Tactical level)
8. Pair Programming
Two brains much better than one ...
Two developers working together on the same code
One driver, one observer - Switch every 15’
Much better concentration
Training - Sharing best practices
Collective code ownership
Photo by rafa-alves - CC-BY-SA
http://www.flickr.com/photos/rafaelmob/4669642298/
9. Collective Code Ownership
#include <stdio.h>
No-one ‘owns’ a particular module or piece of char *msg = "Hello Worldn";
code
int main(int argc, char **argv)
Every one can comment or commit in any {
piece of the code while (*msg)
{
Every one is responsible for the quality of the putchar(*msg);
msg++;
code
}
}
10. Refactoring
Start by writing the simplest code for the task at hand
Then when you need to extend it, refactor to make sure it
remains clean, clear and concise
Can be as simple as:
Renaming classes when their role changes
Making sure the same concepts have the same name
everywhere
Remove useless code and Factor duplicate code
11. Test Driven Development
Write test first, then the code
Improves the design of the code
Future proof
Better than a lot of documentation
http://www.javacodegeeks.com/2012/05/test-driven-development-win-win.html
12. Continuous Integration
Automates the build process of your code
Email the team when a test or build fails
Provides up-to-date “snapshots” of the code
Improves collaboration
Reduces time spent on tedious tasks
14. Standup Meeting
Every morning, members of a project meet for
a standup meeting
Says what she did yesterday
What she will do today
What are the potential problems
Improves communication in the team greatly
Keeps people focused and coordinated
Helps avoid wasted time
Photo by Alexander Ljung - CC-BY-SA-NC
http://www.flickr.com/photos/alexanderljung/3041180268/
15. Kanban (aka Post-it board)
Three columns on the wall: Todo, In Progress, Done
One post-it for each specific task (not feature - task)
Updated in “real-time”
Define “Done”
Visible progress
Avoid wasting time on not important tasks
Forces everyone to thing about the tasks
Trust-me: Post-its are much better than any software... Photo by @Stephen - CC-BY-NC
http://www.flickr.com/photos/hdbizblog/4296189727/
16. Time-boxing - Sprint
Define time boxes for your development: sprint
1
Define what you would like to do in that sprint and do
not change it once started
2
Release a working product at the end of each sprint
Gives some stability to the team and allows the client to 3
change priorities
Gain experience on how much can be done in one
sprint
17. Backlog
A list of all the Use Cases that need to be
developed
Estimated with a Complexity
Prioritized by the Product Owner
Feeds new sprints
Oriented towards the user (use-cases)
Enables Release Planning
Copyright 2005 - Mountain Goat Software
18. Retrospective
At the end of each sprint, the team takes some time to
think about what went well, what needs improvement,
the ideas that came up and questions
Vote for the 3 most important things
Take one action to improve/maintain each voted item
Continuous improvement
19. Retrospective
At the end of each sprint, the team takes some time to
think about what went well, what needs improvement,
the ideas that came up and questions
Vote for the 3 most important things
Take one action to improve/maintain each voted item
Continuous improvement
20. Retrospective
At the end of each sprint, the team takes some time to
think about what went well, what needs improvement,
the ideas that came up and questions
Vote for the 3 most important things
Take one action to improve/maintain each voted item
Continuous improvement
21. Practices to take home today
Pair Programming
Collective Code Ownership
Refactoring
and agile values:
Test Driven Development Continuous Improvement
Kanban Communication
Standup Meeting Courage
Time-boxing - Sprint
Backlog
Retrospective
22. Thank you!
Refactoring: Improving the design of
existing code (Martin Fowler)
Let’s Play TDD Development (youtube)
Scrum and XP from the trenches
www.sarfata.org Scrum Guide
@sarfata
thomas@sarlandie.net