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.

Monday, January 18, 2010

Agile Values and Principles Should Guide Your Practices

In a recent meeting I was in we were having a discussion about a paticular process (I leave the exact process and practice off on purpose) and one person was saying it should be mandatory to perform a specific practice. This paticular practice is a bit heavy and was put in place because some legacy products/teams had some very bad habits and the code was really unstable. My first desire was to throw my hands up and discuss and say that it was stupid. Luckily, my more sensible side asked what is the goal of the practice? This lead to a discussion identifying the goal of the practice and how individual teams might need to meet the goal but not neccesarily with that specific practice.

As with any area of our work when we get bogged down in the day to day of doing things many times we forget why we are doing certain things. New people come on the team and challenge a practice and we get defensive and walls go up. We do not want to be in a position where we feel we must defend a practice or a tool for that matter. These or things to help us a meet a specific goal and that goal is what is the important part.

Since we want, or I hope we want, teams that are continually improving we need to understand what is the goal of the practice and then verify that both the goal and practice are inline with our values and principles. Let's look at a commone agile practices and the goals, values and principles behind it.

A common agile practice is TDD. Starting from the agile manifesto: TDD supports the value of "working software over comprehensive documentation" by having a set of tests that can be used to continually verify that the software is working. As an added benefit TDD also gives documentation of how the software actually works as well. TDD support the value of "respond to change over following a plan" by allowign change to be safer. Change traditionally is seen as dangerous but TDD is one practice (but not the only practice) that helps make change easier and faster.

Moving to Lean principles: TDD supsorts the Lean principle of "build integrity in". With TDD you are thinking of the integrity of the system from the beginning, before you actually write a line of production code you are considering what it should do and building a mechanisim to verify that it does it. TDD also supports the Lean principle of "eliminate waste". Rework and defects are waste in SW development. Since the test is written first TDD helps prevent the creation of defects and reduce the amount of rework by using the tests to verify that the current changes broken some part of the system. TDD also supports the Lean principle of "amplify learning". I can run the tests often to verify current changes have not broken anything.

By understanding the goals, values and principles behind the practice we have the ability to adapt the process to the changing needs of the customer and team. If we stop doing TDD how will it affect our ability to deliver often? Will it affect the quality and therefore increase rework? Is there some other practice(s) that it can be replaced with? What is the cost of the other practice(s) in comparison to TDD? Who are the customers of this practice? How will any change to the practice affect the whole system not just me? TDD is a practice that adds a lot of value and is backed by many principles and if you decide to replace it you will need to answer a lot of questions. Other practices have fewer goals and there will be more options available that may fit different situations better.

Focusing on the goal, principles and values is what allow a team to improve and adapt to change. If our practices become our goals we will fail and our teams will become less productive. Stop getting defensive when someone challenges you to change. First make sure you understand why you are performing a practice. Explain to them the goals you are trying to achieve with a practive. Validate that it does not violate the values and principles you are following. Does it look like it could make the team better? If so give it a try and see if the team gets better or worse and then adjust appropriately.

But please do not stop doing TDD. :)

Simple GivWenZen Example Screencast

Here is my first try at a screencast. I really like the screencast that UncleBob has been doing so I decided to give it a try with GivWenZen. Not only was it fun but very easy using Screencast-o-matic.

More screencast to come soon!