Does your job define who you are?

I've been thinking a lot lately about how intertwined our jobs are in our lives and our identities. For some, a job is simply a way to pay the bills. For others, their job is as much a part of their identity as their education, their hobbies, or even their families. The thing I've been wrestling with is whether your job defines who you are.

What your job says about you

It's interesting when you really sit down to think about it because you can actually deduce a lot about a person just by their job. For instance it can tell people or at least be an indicator of

• Your relative education level
• Your relative intelligence level
• Your interests
• Your hobbies
• How motivated you are to succeed

For example, if you meet someone who's job is software engineer you can be pretty confident that they've got at least a bachelors degree (most likely a bachelors of science) and could have a masters degree (which is more common these days).

Knowing their employer can possibly tell you even more. For instance someone who has been at their job for at least a year at Google, Amazon, Apple, Facebook, or Microsoft will tell you that the person is probably slightly competitive, most likely always excelled amongst their peer group, and wants to work on problems that affect a large user base.

What your job doesn't say about you

With the exception of a few job categories, your job likely doesn't say

• Whether you are interesting or not
• Whether you have social skills
• Whether you are emotionally mature
• Whether you are kind or cold
• Whether you are empathetic or apathetic
• Whether you are selfish or selfless
• Whether you prioritize your family first

To know these things, you have to actually know the person.

Does your job define who you are?

Now we're back to the original question that started this post. Given the above, I think that your job says a lot about you and it can describe your attributes well. But it cannot define you.

Redefining federated identity and authentication

Recently I've been thinking a lot about Federated Identify. In the technology industry it feels like we're always on the constant hunt for the perfect solution when it's been sitting under our noses the whole time.

The Problem Space

At it's heart there are two things that are being solved for. First, how do I authenticate that you are who you are? Second, how do I share basic information in a secure way across multiple systems.

The first problem is a somewhat straightforward problem to solve. While in recent years we've seen advancements in bio-metric authentication, largely authentication is achieved in the form of some sort of username and password combination.

The second problem is not as straightforward to solve. There are a lot of systems that we use everyday ranging from social media to more crucial services like banks and utilities that need a variety of information about us on top of the typical authentication that we are who we say we are. Social networks need to know who your contacts are, what your calendar data entails, who you converse with and when you're available. Banks and utilities need to know more basic information about you such as your mailing address and phone number.

Having a single canonical source for all this data sounds like a great idea doesn't it?

The Problems With The Problem Space

Federated identity and authentication come with the promise of managing your authentication and personal information in one place. In theory that's achievable, but it practice it's a lie. Users still have the burden of managing multiple profiles, duplicating information across sites, and figuring out each sites different privacy policies, what they do with your information and what information they share (or sell) to others.

Again, if there were one true canonical source for this information this wouldn't be a problem, but history has shown that there isn't going to be one canonical source. In fact history has shown that we've made the problem worse. Instead of having one place to manage data we've got a dozen. To make matters worse, most of those places do not stay in sync and we're forced to either deal with inaccurate/out of date data or to spend a lot of time keeping all our data up to date.

Still aren't convinced, how many of these federated identity and authentication sites do you have an account with?

• Microsoft
• Google
• Yahoo!
• Twitter
• LinkedIn
• PayPal
• Foursquare
• Mozilla
• Amazon

My guess is that you have an account on at least half of those, if not all of them. That data point in and of itself is proof that federated identity doesn't solve for the you're only going to have to manage your data in one place problem.

Redefining The Problem

I'd like to propose that we redefine the problem in such a way that

1. We allow users to store their personal data wherever they want
2. We make that data accessible and 100% in the control of the users
3. We authenticate users in such a way that they only have one username/password combination to remember and changes to their password are instantaneous across all sites they authenticate with.

The Solution

Solving this problem isn't actually all that difficult. It can largely be done with existing technologies and open standards.

Authenticate users using their existing email service provider

If every email provider exposed an OAuth provider that was built on top of SMTP Authentication then we'd have this service today. The user would be redirected to their email provider and asked to authenticate. They'd give their email provider their username/password combo and then it would issue an OAuth token to the service.

The users email/password combination are never shared and users don't have to remember multiple usernames/passwords. It comes with the added benefit that when they change their email password it's instantaneously reflected in any service they use.

Again this could be built into every existing service now using existing standards.

Allow users to store data wherever they want

As a user I should be able to store my data in the service of choice. I should be able to store my data in Facebook, Microsoft, Apple, Google, Amazon, or <insert your favorite cloud provider here> service. If I want to use another service then I should be able to point it at where I store my data and it should be able to read or modify it as I choose.

This also could be done today using existing standards and protocols. If each cloud provider did the following we'd liberate our data and ourselves from having to choose how and where we store data.

1. Expose CalDav, CardDav, and WebDav APIs to read/write contact, calendar, and file data.
2. Provide a mechanism that allowed users to grant access (OAuth anyone?) to their data from another service.

Example of how this would work in the real world

Let's say I decide that I want to use GMail as my email provider. I go sign up and GMail creates an account for me and exposes an OAuth provider for anyone that wants to integrate with my GMail account.

Later, I get an iPhone and want to use iCloud and Apple's calendar. When I sign into my iPhone I tell Apple that I use GMail for email and it also authenticates me using GMail and OAuth and creates an account for me. Part of what I get is a calendar, contact management, and file storage.

I then decide I want to join Facebook. I go to Facebook and instead of creating a new account, I tell Facebook to authenticate me using my GMail email address. When it authenticates me I tell GMail to give it access to my calendar, contacts, and file storage. Facebook creates a new user for me, identified by my email address. Facebook then asks if I have a calendar and contacts and I point it at Apple, who has exposed a CalDav and CardDav server. Since Facebook has been approved for those services Apple is able to validate I am who I say I am and Facebook now has access to my contacts and calendar. In fact Facebook could also use my file storage as the primary place it stores photos and videos I upload.

As a user I get to control my data AND still get access to all the great services I've come to enjoy. We all win.

Smartwatch Manifesto

As I mentioned in my previous post I've owned a Pebble Time for a few weeks now which basically makes me an expert on all things smartwatch related (please note the sarcasm). But seriously I do think I have a much better understanding now of what a smartwatch is and should be for. So here's my Smartwatch Manifesto.

A Smartwatch is a companion not the star of the show

What I mean by this is that a smartwatch should help you with some other task, unrelated and uninitiated by the watch (with the one exception of telling time). To prove this I present a simple test. While standing up straight, hold your arm out parallel to the floor for 3 minutes without putting it down. Go do it now. Sucks doesn't it?....

You're obviously not going to be interacting with your watch in that position but that test is to show you that it is unnatural for you to not have your arms at your side or in a sort of resting position. When you initiate doing stuff with your watch it makes you do something unnatural.

The goal of a Smartwatch app should be to get you in and out as quickly as possible

This rule is a direct result of rule #1. The ways that a smartwatch app can enable you to get in and out as quickly as possible are:

• Present the minimal amount of information on the screen as needed to fulfill the task.
• Be context aware, and use that context to decrease interaction.
• For example, if you know the user is running or biking, default to voice control rather than button or touch input.
• Allow voice interaction to both initiate activities as well as respond to notification.
• When using voice dictation, validate using audio.
• You already know audio is okay since I initiated the interaction with voice.
• It prevents me from having to focus on my watch instead of my primary activity.
• It helps me get the context someone else will hear/read my statement in.

A Smartwatch needs to enhances communication

Society today communicates via voice, touch, and text. We use different means of communication in different contexts. A smartwatch should enhance communication in the context the user is in. For example; when I'm out and about I will primarily want to respond to things using voice commands as it's easier than having to pay attention to the screen.

For each primary means of communication that the smartwatch enhances the wearer should be able to initiate the communication, see current meta-data about the communication, and respond to or interact with the communication.

Primary means of communication that a smartwatch should enhance include:

• Phone calls
• SMS
• Email
• Calendar

A Smartwatch allows you to get a glance at meta-data

Minimization of data should the the smartwatch apps goal. The watch has a smaller screen and different input. Therefore it should initially present meta-data and not full data. Allow the user to dig in where appropriate but make that the exception to the rule and not the rule itself.

For example, email meta data should be from, subject, and first line or two. I know the date since it came from a notification, and it was to me or I wouldn't be reading it (even if I was BCC'd the primary purpose is that I read it, and thus it is to me). I should be able to decide from the meta-data whether I want to dig deeper into the full data.

A Smartwatch is context aware

Watch wearers typically wear their watches all the time. The watch should be able to determine the wearers current activity and respond in kind. If I'm moving the watch should be able to determine the difference between walking, running, biking, or traveling by car or plane. If I'm still the watch should be able to determine (using enviornmental and other factors like my calendar) whether I'm asleep, in a meeting, on the couch, or at a movie.

Watch app makers should be able to ask what the context of the user is so that the user is able to interact with the watch in the most appropriate fashion for their current activity. For instance, if I'm biking I should be interacting with the watch primarily through voice and audio playback.

A Smartwatch has a long battery life and is water proof

Watches are cumbersome to put on and take off. Therefore a smartwatch should optimize for not being taken off. This means that it needs to have a long enough battery life that having to charge it is the exception to the rule and not the rule itself. This also means that the watch needs to be waterproof in order to allow me to take a shower or go swimming.

A Smartwatch enables fitness tracking

For a smartwatch to enable fitness tracking it needs to be able to determine the following:

• Current Activity (walking biking running swimming)
• stair counts
• step counts
• elevation gain/loss
• heart rate
• calorie count
• pace
• sleep tracking

Pebble Time: My (incomplete) Review

About a month ago I received my Pebble Time. I missed getting in on the Kickstarter campaign but I was able to take advantage of the pre-release ordering through Best Buy. I ordered early enough that I got my Pebble Time the first week of July.

My review of the Pebble Time isn't going to be a standard review. Mostly because I don't think that most people or tech publications really know what a smart watch is supposed to do. Most of the reviews that I read talk about them as if they're gadgets that serve a purpose on their own. I've got some thoughts on that which I plan to publish here in the next couple of weeks.  But at the core I've decided that a smart watch is a companion.

In this post I'm only going to go over what I like about the watch. I'll go over what makes the watch a good companion. Honestly there's not much I don't like about the watch. All it's flaws have been covered elsewhere on the interwebs.

The Watch ... As a Watch

A watch serves two main purposes for me. First, it needs to tell me the time. Second, I need to be able to set an alarm. The Pebble Time, like the Pebble before it, is actually pretty awesome with regards to telling time in that you can install custom watch faces. I've downloaded several different ones and I would say that about every week or so I like that I have the option to use a different watch face. It actually makes the watch feel new for a day or two with a new face.

The Pebble Time also does a good job in the alarm category. In fact it's alarms are better than most watches because of the flexibility. It's similar to the alarm clock on a smart phone in that you can set multiple alarms up and have them set for a single occurrence, every day, weekdays, weekends, or a custom set of days during the week. The alarm vibrates and has been good enough to wake me up in the mornings.

Timeline

I didn't own the original Pebble so I don't know what the OS (operating system) was like. But the Pebble Time OS is very intuitive. There's four buttons on a Pebble Time; one on the left side and three on the right. The one on the left is the back/home button. The top right button will go up in a list or if you're on the home screen will take you into your timeline starting at the most recent past. The bottom right button will go down in a list or if you're on the home screen will take you into your timeline starting with the most recent current or future events. The middle right button allows you to select something in a list and when pressed on the home screen takes you to the list of apps on your phone.

As of right now I don't have a lot of stuff on my timeline but the stuff that's there is useful. I have my calendar, ESPN and weather on my timeline. The calendar is probably the most helpful as I don't think I realized how often I pull my phone out of my pocket just to look at my calendar. I probably save myself from pulling out my phone one or two dozen times a day. That in and of itself is probably worth the price of the watch.

Voice Responses

The Pebble Time comes with a microphone so that you can respond to emails and text messages right from your watch. This is hands down the feature of the watch I love the most. I HATE making phone calls so I mostly stick with text messaging people. I probably use voice dictation to respond to 20 text messages a day.

There's one huge miss with voice on the watch though. You can only respond to messages with the mic, you can't initiate text messages or emails with it. Email would be more difficult but I don't actually understand why initiating a text isn't there on day one. The functionality to get a list of contacts, get the cell number for a particular selected contact, and then send an SMS on Android and iOS isn't that difficult. So it surprises me that their Pebble app didn't add this functionality so that they could implement it on the watch.

The accuracy of the speech to text translation is scary good sometimes and hilarious at other times. For me, I've found that it has a direct correlation to how loud I'm talking. When in the office I try to whisper and the mic doesn't like that at all.  I've found that if I talk at a normal volume with my normal cadence there are just a handful of words it confuses. For some reason every time I say "and" it thinks I'm saying "end". I'm wondering if there's some Pacific Northwest accent I've got that's throwing it off. At the end of the day it's accurate enough that I still use it 10 - 20 times a day.

The App Store

I'll start by saying that there are a lot of apps for the Pebble. So many in fact that it highlights how awful the Pebble app store app is. The search is truly terrible, often not returning apps that contain the search term in their name. There are only a couple of categories that you can browse and they're not very helpful in my opinion. Most of the apps I use I found by either word of mouth or by spending an hour trolling through the app lists looking for something interesting.

I've found that there are about a dozen apps I've downloaded that I use daily/weekly. Cards for Pebble is a great app because it let's me see stock quotes and weather very easily. Pebble Music is the best music app I've tried so far. It's companion app isn't free but it's worth the money. I can initiate and control music playback entirely from the watch which is awesome as I'm a bike commuter and I often have my phone in my bag and am wearing bluetooth head phones (in one ear of course). Pebble Movies is great for getting movie listings and showtimes. CatchOneBus has been great when I'm riding the bus instead of biking. Other useful apps include Timer+, ESPN, Misfit, and Ventoo Bike Computer.

Battery Life

The battery is awesome. I regularly get 5 days out of a full charge. Which means if I charge it Sunday evening I'm good for the week. When I'm using it for development I get less battery life because I'm using it constantly for hours upon end. A note of caution, some watch faces with heavy animation will kill your battery quicker. I think it's key to find a watch face that looks great but isn't updating every second.

Would I Recommend It?

If you're looking for a companion to your phone that allows you to pull it out of their pocket less often then this is the watch for you. If you're looking to replace your phone with a watch then you're going to be sorely disappointed with every smart watch on the market.

Agile Development: Demo Day

So far in this Agile Development series I've:

• Made the case for Scrum
• Defined who and what a sprint team is
• Walked through the anatomy of a sprint
• Provided tools for determining sprint duration
• Detailed what daily stand-up looks like
• Provided the typical workflow for planning a sprint
• Outlined the sprint retrospective

In my final post in this series I'll explain demo day and how it relates to agile development.

What Demo Day Is

As I've been saying all along in this series, one of the main objectives of Agile is to reduce the time it takes to complete the feedback loop. The loop is complete when the stakeholders have reviewed the feature(s) and signed off on them. Demo day closes the loop and provides the stakeholders with an opportunity to affect change.

I like to think of demo day as the bow that is tied around the sprint. It brings closure to the sprint process which started with sprint planning. At it's core the sprint demo is the teams opportunity to showcase what they've built during the sprint. Beyond that sprint demos can also be a useful tool leading into the next sprint planning phase as the product manager may change the plan for the next sprint based on the progress of the team.

There are two main parts to demo day. First is to review the work completed and not completed during the sprint. Second is to demonstrate the completed work to the stakeholders.

Reviewing Work

Reviewing the sprint work should be comprised of three things. First the team should very briefly call out what stories the team accepted into the sprint during planning. Second the team identifies what stories were added to the sprint after the sprint started. Finally the team goes over what stories were not completed during the sprint.

It's important to note that the review is not an exercise in excuse making or justifying not getting everything done. It's main purpose is to close the feedback loop with stakeholders and set expectations prior to heading into sprint planning.

The Demonstrations

Demonstrations are just that, demoing what the team built during the sprint. Typically the demo is limited to the user impacting aspect of the features the sprint team worked on during the sprint. The team reviews the features to ensure they are complete as well as provide product management the opportunity to get clarifications on behalf of the customer.

One mistake I've often seen people make is trying to "demo" spreadsheets or powerpoint bullets. This usually happens because the team was mostly in bug fix mode or works on non-user facing features. I would encourage teams in this situation to get creative and tell a story using charts, graphs, and metrics instead of showing data in excel or a list of powerpoint bullets.