Agile Decisions…

When I became “Agile” the first thing that changed about how I approached my software development was my daily decision making.  Rather than following a set of rules or going on an “Agile” course or directly following a book I began to ask myself some questions. Different questions every time, but they followed this broad flavour:

  1. Is what I am doing now going to generate feedback?
  2. Is what I am doing now going to be visible?
  3. Can I easily explain it to someone
  4. Can I get it done in a short period of time

Points 1) and 2) are the most pertinent here and I will briefly explain below:

1) Is what I am doing now going to generate feedback?

Yes? Great! do it. If you get feedback on it then you know straight away whether its good or not.  (Remember that feedback without conversation is just criticism). If “No” then you need to ask yourself whether its worth doing.  Are you commenting code that will never be read? Are you doing something that will never be noticed?  If its an important piece of code that only you can write, consider telling someone about it; code written by only one person is more likely to be bug ridden and a “problem sticking point” than code that has been viewed by more than one person.  Even if they are not an expert or a fan of pair programming its a good idea to talk someone through the code! Firstly it forces you to re-read the code, talk about the code, hear yourself talking about the code and ALSO your peer might be able to see improvements that can be made in the code.

2) Is what I am doing now going to be visible?

Agile is all about visibility, how are you monitoring your progress? If the piece of work you are doing not going to be seen why are you doing it? This overlaps somewhat with point 1 above.  However, visibility allows for accountability.  Accountability allows for priority.

This is where you must be thinking of how your time (ideal hours or points) is being spent on the project.  If what you are considering doing now cant be accounted for as something that is visible then ask yourself why are you doing it?  There are two broad areas of accountability you can involve yourself in

  • Project based (time spent on user stories)
  • Learning based (time spent on learning)

Anything else.. its just personal admin (or Foosball).

How do you make yours ?

This entry was posted in Core Agile. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *