Tuesday, January 19, 2010

Common Practices that Back Agile Principles and Values

After I wrote the post on principle and values guiding the practices I thought it would be a nice exercise to take the values from the Agile Manifesto, Lean and maybe XP and put some of the practices from agile that support those values and principles. Here is my first try at it. None of these practices or absolutes but all of them add some value and in the end we need to understand how they support our values and what goal(s) they have. In the case that we cannot do them (or simply are not doing them), such as a distributed team cannot be in a single open workspace, we need to look for practices to meet those goals and support the same values and principles or be willing to accept that the goal will not be completely met.

Individuals and interactions over processes and tools

Related Agile Values and Principles: Intense collaboration, Amplify learning, See the whole, Empower the team, Feedback, Open and honest communication

User Stories and Acceptance Criteria - to me the best definition for a user story is still 'a place holder for conversation'. One goal of the user stories is to drive continual conversation around a piece of business value so that the user gets what they want and it happens through conversations.

Daily Scrum/Standup meetings - daily the team gets together for interaction and team building. Some goals are for the entire team to communicate daily to focus on the highest priority items and make sure all problems are being addressed.

Open workspace - When we cannot see each other we tend not to interact well and it is much easier to just point the finger of blame. One goal of the open space is for people to talk and work out the issues as soon as they come up. It is meant to promote communications.

Customer is always available - see the same item under customer collaboration.

Retrospectives - Retrospectives probably support all of the values but more often than not they end up being about improving how we interact. The goal of the retrocspective is to improve on the outcome of all of the practices we have put in place including the retrospective itself.

Working software over comprehensive documentation

Related Agile Values and Principles: Build integrity in, Intense collaboration, Embrace change, Quality work, Eliminate waste, Amplify learning, Feedback

Code Inspections - One goal of code inspections is to catch issues early, improve the code maintainability and quality, as well as learning.

Test Driven Development - One goal is to drive the quality from the beginning. Another goal of tests is to verify our software is working as expected. The nice thing about good tests is they also document the behavior of the application or a part of the applicaiton.

Integrate often - Integrating the code often helps keep the code in a working state which allows us to deliver often. Big/delayed merges have a higher risk of breaking something.

Deliver often - Delivering working software to the customer is great documentation. One goal is working software continually.

Customer collaboration over contract negotiation

Related Agile Values and Principles: Intense collaboration, Embrace change, Eliminate waste,

User Stories and Acceptance Criteria - Stories are the business value we are delivering and one of the major pieces which are collaborted on.

Deliver often - Not having a fixed contract is scary for a customer. Working software delivered often is a confidence builder that can help increase the collaboration.

Customer is always available - Some goals here are to make sure the customer gets what they want and the team is not waiting or blocked and is therefore very productive. The customer and the developement team or always talking.

Behavior driven development - Goal is to document business issue the application should solve for the customer. This is a collaborative effort that helps everyone understand what the goals of the applicaiton are.

Iterative Planning - One goal of iterative planning is to deliver the most important items to the customer.

Responding to change over following a plan

Related Agile Values and Principles: Decide as late as possible, Incremental change, Courage, Decide as late as possible, Decide as fast as possible

Iterative planning - The shorter the iteration the more often we have good points in time to make changes without interruptions.

Limit work in progress - One goal of limiting work in progress is to allow change without interrupting the flow of the team. A lot of work in progress means the team must stop something in progress, which is potentially dangerous and definitely a waste of effort, or we must wait longer to get to a point when soneone is ready to start a different piece of work, which delays the ability to make change.

Refactor - Goal is clean code. Clean code leads to the ability to change easier.

Collective ownership - One person 'owning' a part of the application is a guarantee to slow the ability to change and everything else.

Unit tests and acceptance test - One goal is to give the team confidence to make a change.

Automation - There are many things we can automate: the build process, code generation, deployments, release, etc. Most of these automations should have a goal of being able to respond to change faster.

As I started to put this together I realized that there are some practices that support other practices and the practice may be one or more steps away from the actual principle or value. Measuring welocity is a good example of this. Velocity is a measure of how much work a team can do in a short fixed period of time. Velocity supports iterative planning which in turn is based on several of the values.

Comments are welcome and desired on these items. I would really like some help with added other goals for practices that are related to each value and other practices that go with each value and the goals of those practices.

No comments:

Post a Comment