"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"
That's the first of the twelve agile principles, and arguably the only one that stands heads-and-shoulders above the rest. The other eleven principles could be described as a mix of technical and practical guidelines with more or less the same importance as their neighbors.
The principles are targeted, yet generic at once in order to accommodate the various modes of software development. They are flexible enough to help us make decisions when building enterprise software, commercial software, open source software, line of business software, or hobby software.
The principles help guide decisions, but are there extreme environments where they begin to break down? What happens when a project's velocity, the number of features that can be produced in a set period of time, trends towards zero or grows towards infinity? Do some of the principles become more important than others? Do any principles become irrelevant, essentially falling off the list?
One could imagine other environmental extremes that may also affect the principles, like writing software without a customer in mind, writing software that no one will ever use, writing software with extremely short or expansive deadlines, software that is incredibly small or large, and writing software where there is an absence or abundance of trust, just to name a few.
The disc golf app that Adam and I have been working on has been a bit challenging to manage with the agile process because our velocity so so low - we are doing good when we are able to dedicate 6 hours a week each to the project. Based on the few agile teams I've been on and their average hours-to-points (I know, that conversion can make a scrum master pucker) that could yield a 10-to-15 point velocity at a one-month iteration. It would be common for teams to do 70 points in an iteration of two or three weeks, so 10 points in a month is like a turtle's pace.
Our first iteration, which was the month of November, was just two stories. I set up the architecture and Adam did some user interface design and mockups. I don't think either of us were ready to close out our stories, so we probably didn't even burn down.
With a velocity so low, I argued that we shouldn't task out our stories. I didn't want to allocate time to think about breaking out our user stories into hourly tasks like we would normally. Our process was starting to bend to our new circumstances, but I think that's OK considering two important tenants of the agile philosophy: 1) Do only the what you need to get well designed, working software delivered, and 2) Use the periodic evaluation of what went well, what could have been better, and how you are going to improve to tweak your process.
After our first iteration, we decided that we did need to put a little pressure on ourselves in the form of a goal to strive for. Each year in February there is a tournament here in Lincoln called the Ice Bowl where you play no matter the weather conditions. You may need snow shoes or chemical heating packets in your shoes and extras in your mittens, but you play. We are going to have a working scorecard for the 2014 Ice Bowl. It will give us something to work towards and help us follow the simplicity principle - only do what is necessary, no more.
Our scrum master friend and sometimes boss Keil wondered at my use of the term "near-zero-velocity" when talking about our starting to abandon parts of our process. He wrote, "it makes me wonder what the point of any project is if you aren't willing or able to put more effort into it than is necessary to keep it on life support. Assuming we never have enough time to get it all done, does it make sense to say we're 'working' on a project where we never make progress towards completion? Maybe we should just shelve the project for a later time when it becomes a higher priority than the other attention grabbers that surround us."
I wonder if he'll be right or not, if we'll end up shelving this project because of lack of momentum. With family and work, it's hard to stick to a system of working on a side project. Adam and I both have young children that we don't want to sacrifice our family time with to spend time on this project. On the other hand, we both need an outlet for trying new technologies because we are both, at separate jobs, working with code that is several years old. If we want to stay fresh, we have to find a project to work on outside of 8-to-5. My primary reason for working on the Disc Golf App is to learn new technologies, build my portfolio, and share ideas via blog posts to help other developers looking to learn. I told Keil that even if this app never gets finished, I will consider it a success if I can use it to learn some new tricks and share them with the community. It is a principle that falls outside of the agile principles, but it trumps the twelve other principles for me for this project:
Strive to hone your craft by learning and applying new techniques and sharing that knowledge with others so that they may benefit.