no title


One of the exciting new Metro rail lines! These machines are incredible.

Read More

Going Phoneless

My Nexus 5′s power button stopped working about a month ago (a common problem, it seems). After a quick call to Google CS and reminder that I’m out of warranty, I decided to take the opportunity to try living without a phone.

It’s been… actually really easy. I use Google Voice for my phone number, so I can get texts and calls from any device that I’m logged in to. But the other reason I think it’s been fine is that I realized that there a few major “categories” of my time:

  1. When I am near my computer or iPad with internet
  2. When I am with other people who have phones
  3. When I’m not near internet or people I know, but don’t need to be in communication
  4. When I’m not near internet or people I know, and I do need to be in communication

The first is most of the time when I’m at home or at work. The second starts the moment I encounter the first person I’m meeting with outside of number one. The last two are what surprised me. 

Everyone thinks that being without a phone is an impossible task because we use it so much in our idle time. That was me a month ago, browsing the internet or chatting as I walked to the car or between sets at the gym. But after an incredulously short time, I stopped missing having my phone for these moments. Although there are still things that are put into the fourth category (largely when driving in case of an emergency), I found that almost everything not in the first two can fit into the third.

(I’d say that being phoneless has contributed to posting on here more often. I read more and have more time to think and come up with stuff I want to talk about)

That said, I got a backup phone (thanks, Tesia!) and have some replacement power buttons on the way to try to fix it myself. It looks like a fun little project, but I am going to rethink what role a phone has in the small moments of my life.

image
Read More

Your Agile Project Needs a Budget, Not an Estimate

Your Agile Project Needs a Budget, Not an Estimate

Something that we have struggled with is keep the expectations of shareholders realistic without making the project sound incredibly expensive before it even begins. I like using estimated range of costs, and I like what the the author say about how we only have enough information if the project budget is outside those bounds. But a problem I’ve experienced is that stakeholders balk at the higher-confidence but higher-cost upper bound estimate, while having a hard time accepting the uncertainty of being within those bounds. 

We’ve fortunately been able to build trust with a lot of our customers through our previous projects– trust that we are giving realistic estimated ranges and not trying to deceive or overbill them. Transparency along the way is necessary to maintain that trust that that we’re making convergent progress.

The Monday demo I’m about to give is one of the best (and fairly inexpensive) ways we are implement transparency. Nothing makes people feel better about spending money than seeing what that money is going towards. For a recent large project, we built a POC that showed them how we develop things and how we do “transparency”. Seeing weekly/biweekly releases and demos is sometimes a shock for a customer not used to scrum and gives them a lot of confidence that things will get done (or even if there are problems, it’s transparent and a resolution can be worked on very quickly).

Plus demos get us great feedback from the people who actually use and maintain the system.

Read More