Rusty Divine

Live, Love, Learn, Teach

An Agile Principle for Hobby Software

"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.


I recently changed jobs. The upside is that I am really enjoying the team I am working with and the project we’re working on. The downside is that I no longer work with my good friend Adam.

Today, I am happy to say, we have decided to embark on a side project so that we can continue to work together. Of a list of 15 or so ideas, we came back to the one idea we each separately had when we started working together a year ago – a Disc Golf app.


It’s funny that when thinking about a project done on my own time, my first tendency is to disregard any formal process and just git ‘er done. Why waste time on user stories and mockups – I know what I want, right? Do we need iterations, daily stand ups, and burn down charts?

Back at our former employer, we honed our process for gathering requirements and prioritizing them. We called this an Agile Assessment. For a nominal fee – enough to discourage anyone who wasn’t serious, but not enough to actually break even – we would meet with all the stakeholders we could in one 4-hour meeting. First, we’d lay out the agenda and ground rules. We’d then spend about 20 minutes to define a project objective that could be concisely written on our wall board. From there, we discussed some of the obvious users, and then started brainstorming features and recording them in the form of user stories with a title and conditions of acceptance listed for each one. Each of the titles would go onto a yellow sticky note, and the rest of the story would be recorded in a spreadsheet. When we had 20 minutes remaining, we’d ask all the stakeholders to take the sticky notes and order them from gotta-have to would-be-nice. After agreeing on the order, they would draw a line to separate what had to be there to make the most basic solution from the rest – everything above that line was in our Core Feature Set. Adam and I would then spend a fair amount of time researching and designing the solution (30-40 hours) and present the customer with a set of design documents and a fixed-price quote for the solution.

When we won a project, we broke it into two-week iterations and managed the stories and burn down using TFS. Each day we’d have a 5-10min discussion of the project and include the product owner via a phone call. There was a daily burn down chart emailed out to the team, and at the end of each iteration a demonstration of production-ready code was shared with the customer followed by a retrospective that drove continual improvement of our process.

We learned to love running projects this way and saw how product quality and team communication improved.

Going Forward

How much of this process should we bring forward into our side project? I don’t think we’ll be doing daily meetings – we both have young children and will be doing very well to spend 8 hours a week on this project. Having a product backlog and burn down seem like a good idea to me, but having a time-boxed iteration will need to be tested. We’ll need to find a new process that works for us, so we should definitely keep a periodic retro schedule.

Why are we doing this project? We both enjoy Disc Golf and we both enjoy learning and working together. This project will give us the chance to try some new technologies and approaches, and keep us interested in learning.

What’s next? My next step will be to look into opening up an account with Team Foundation Service to see if we can use an environment that we’re both accustomed to. We’ll create a product backlog and plan out our first iteration. Who knows where it will take us!