The Pit Of Success

Over the last decade or so I've worked on a lot of teams chartered with building APIs, web services, and/or micro-services that were consumed by external and internal software. When building something that's composed into another system you're inevitably going to have to make design decisions which, if used incorrectly, will not have the desired effect on the system.

A few years ago a former co-worker of mine introduced me to a concept that helped change how I approach solving for this problem. That concept was called the Pit of Success. In it's most basic form the pit of success can be defined as follows:

Pit of Success: being easier to do the correct thing than it is to do the incorrect thing?

So how do we create a pit of success with the products we build? Here's some simple tips.

Solve for the 80% case out of the box

By default the software should solve for the 80% use case. Often this can be accomplished by simply creating reasonable defaults for configurable parameters. The way I like to solve for this is by asking myself the question "what is the out of the box behavior?"

Make the developer do work to harm the system

Most of what we do on the web involves creating, updating, or deleting data. Occasionally we have to build things into a system that can have harmful if used incorrectly. In these particular cases you can create a Pit of Success by making the developer do work to enable the potentially harmful feature or use the potentially harmful API.

Familiarity

Be conscious of the platforms and frameworks that you're working with. Don't invent new conventions that don't add material value to the system. Use idioms and patterns that are natural to the developers of that platform.

What's the measure of success for your project?

When I first started in the software industry I believed that the measure of success for any project was whether or not it shipped anywhere. One of the biggest surprises to me transitioning into the industry was how much software never actually ships. It baffled my mind (and still does) that people could work for weeks, months, or even years on software that would never ship.

What I've learned though in my career is that shipped software is not the right measure of success. USED software is the correct measure of success. No, not re-sold software. I mean software that is being used in the real world by real people/processes to solve real world problems.

Simply shipping software is not enough. Why? Because shipping software that is not used is the same as not shipping the software in the first place. Anecdotally, the top three reasons for software not shipping in my experience have been:

1. The team never reaching feature complete.

2. The project running out of money.

3. The requirements changing so fundamentally that it made sense to just build something else.

#1 and #2 are closely correlated in that #1 eventually leads to #2. All 3 of those situations are symptoms of having a broken process. So how do you fix your process?

Get a product owner

All good (i.e. used) software has a product owner. Someone who is responsible for making sure that the software being built is solving an actual problem and has people who need the problem solved. A good product owner doesn't search for a customer for the software. Instead a good product owner builds software that has people who already need it and figures out how to get it in front of them.

Focus on building individual features rather than a breadth of features 

All too often in the software industry features get built because of some gut feeling of some higher up in the organization. Don't build software this way, it's the easiest way not to have real users. Instead focus on a small feature set (one feature if at all possible) and build it, ship it, and iterate on it.  

Once you've got people using a feature you'll know the correct next feature to build because your customers will ask you for it. The key is, your existing customers. The ones that rely on your software to accomplish some task, will ask you to build something that they need/want. 

Release early, and often

I've talked about this many times but it bears repeating. The only way to build the correct thing is to get feedback on what's being built as soon as possible. The only way to do that is get something in your customers hands as soon as possible, gather feedback, and pivot in response to customers needs. The only real way to do that is to release early and often.

Understanding Trade-offs In Software Development

I've worked in the software industry for a decade and a half as both a software engineer and software development manager. One thing that I've learned to do for the projects my teams work on is to anticipate and understand the possible trade-offs you're going to have to make downstream.

It's a given that something is going to change between the start of a project and when you actually ship that's going to force you to make a trade-off. As I've talked about before, Agile and LEAN allow us to mitigate the cost of making these changes by reducing the time it takes to get and incorporate feedback.

One thing I haven't talked about is how to make the right trade-offs for your product.

Minimal Shippable Product

Understanding your minimal shippable product is the foundation of any trade-off decision you're going to have to make. I'm not taking about a gut feeling about what you're customers may want. I'm talking about understanding what makes your product different.

Some questions to ask yourself to identify the minimal shippable product:

• Does the lack of feature X put my product at a significant disadvantage in the market place I'm entering or are already in?
• Will 80/90/100% of my customers use feature X?
• Will missing feature X make you look stupid? For example, a text editing product without copy/paste or an image processing app without the ability to adjust contrast. 
• Is feature X a key differentiator for my product?
• Can your customers achieve feature X in some other fashion? 
• Does missing feature X cause significant friction for your customers?
• Is feature X on the short list of reasons to buy your product?

Time To Market vs Feature Complete

Another very important thing to consider is how important is time to market vs feature completeness. Are you providing a service that no one else currently provides? Does the market you're entering have a sales cycle that requires you to make a specific date?

Being first to market has strategic advantages that cannot be ignored. But being first to market with a sub-optimal product may hurt you worse than not being first. Apple wasn't first to market with the smartphone, but they offered features that weren't available anywhere else. The converse is also true though, they were first to market with the modern day tablet and it took half a decade for anyone else to really break into that market because there wasn't a compelling enough reason to buy the alternative to the market leader.

Breadth vs Depth

The last major trade-off to consider is whether your product provides a breadth of features which are mostly polished or a sub-set of those features that are fully polished. I'm not talking about your minimal shippable product here. I'm talking about the things that didn't make your MSP list, but may be the right things to build for your customers. For example, if you're providing a parity product, you need to know how much parity you need to achieve to be relevant to your customers.

Missed Opportunities In Travel Tech

I've been doing a lot of traveling lately and I've noticed that there are a lot of missed opportunities and missing technologies that would integrate well into the travel workflow. These opportunities represent ways to reduce friction with customer interaction, which in my opinion, increases brand loyalty.

There are several things that need to happen in order to check into a hotel or rent a car, all of which are time consuming. First you need to show your identification. Then you need to give/confirm the credit card to hold the room with. You then need to confirm you're contact information. If you're lucky this is all, but often you also need to agree to some terms.

Technology can help reduce the friction, significantly.

Digital ID

There needs to be some way to store your state/country issued identification digitally, and only make it accessible when and to whom you choose. I'm sick and tired of having to constantly show my license/passport for identification verification. I know there are a ton of privacy concerns but hey, it's 2015 and the internet isn't going anywhere. It's time we figured this out and stopped requiring people to show physical identification.

Contacts Integration

Why do I have to fill out my name, address, telephone, and email every place I check-in. My phone has all this information already stored in my contact card. I should be able to "share" this info with an establishment if I choose to have it auto-populate any of that information in my records. We already have standards (for example: Bluetooth and NFC) which could be used to handshake this information whenever and wherever we want.

Geo-fencing

I should be able to use geo-fencing to initiate my integration with an establishment even before I get there. For instance, suppose I have a hotel or car rental app installed on my phone and I'm logged in with some way for them to identify me. As I got within a certain proximity of the establishment they would get a notification that I was near and start preparing the paperwork (all automated hopefully). The app would then request that I give it one time access to my Digital ID, credit card, and contact info which I could accept or refuse. If I accept, my check-in is complete and there's nothing for me to do when I get to the hotel/car rental except get my keys.

Proximity

When I get to a hotel or car rental establishment I should be able to walk up to a stand and using my personal device (via NFC, Bluetooth, or whatever) authenticate myself and get authorization for the key. Taking this one step further, why do I need a room key or car key at all? Why can't I use my personal phone to access my room or car. My device is/should be unique.

Windows Support for OpenSSH

I'll admit, I've been a Microsoft detractor for several years now. When I worked at MSNBC (at Microsoft) I was one of the only folks who didn't use Windows outside of work. To me Microsoft was a non-starter because of it's stance (at the time) on both Open Source software and Open Standards.

While Microsoft has A LONG way to go on supporting Open Standards (like CalDav and CardDav in Exchange/Outlook or POSIX at the system level) within their products, they have done a complete 180 with regards to their stance on Open Source software. Open Sourcing .NET was a huge accomplishment but years too late in my opinion. Most of the exciting development that's happening these days is happening on or in support of mobile. Java and Objective-C have taken the reigns there. Because it's much cheaper to run a Linux server than a Windows server in the Cloud coupled with the fact that .NET was only available on Linux through Mono which didn't support all the .NET APIs, Microsoft in the Cloud has not been a major player. .NET not being Open Source until the last year means that it's going to have to fight a giant uphill battle to complete with Java, PHP, Ruby, and Node.

What I am excited about though is the recent announcement that Microsoft has contributed back code that makes OpenSSH a first class citizen on Windows. OpenSSH is the defacto standard for remote management and the fact that you will be able to ssh from a *nix box to Windows will make it easier to integrate Windows into a Cloud based solution that is managed via code (like Chef, Puppet, etc) without having to prep a system image before hand with the Infrastructure as Code tools.

I went into great detail in my #ChefConf 2014 presentation on the legwork you had to do just to be able to bootstrap a Windows server. I'm glad to see Microsoft committed to changing that.

This is a step in the correct direction for Microsoft and one that I applaud!

Year in review (according to just another technology guy)

And just like that another of writing this blog has gone by. When I started this blog I had it in mind to write one longer'ish post a week 52 weeks a year, instead of smaller more frequent posts. I like the cadence and it's worked out pretty well, at least from my perspective.

My daily/weekly readership has grown quite a bit but I'm not convinced that you're all real living breathing humans. My guess is that there are feed bots and link bait bots out there trolling around and my readership increase is at least slightly due to that. The three most popular posts in the last 12 months have been on Agile Development: Sprint Retrospective, Android WebView: HTML5 Video and Rotation, and When Not To Refactor.

Wearables

We've seen a lot happening in the technology industry with regards to watches/wearables. Apple released the Apple Watch (which I still call the iWatch), Pebble released it's new Time watches (Time, Time Steel, and Time Round), and there have been a whole slew of wearables released on the Android Wear platform. I have a Pebble Time and really love it.

What I'd like to see in the next year is for wearables to not try to replicate phone interactions, but instead try to solve problems they're form factor is better at. For instance, put a gps in a wearable and provide location based services via geo-fencing. I'd also like to see a Swype like keyboard for Pebble (though it would need a touch screen).

Streaming Video

While I'm still unhappy about the state of streaming video, there have been some pretty notable events in the past 12 months. Transparent, an Amazon Instant Video series, became the first streaming service series series to win a Golden Globe (it won two; Disclaimer, I work for Amazon). Apple announced a new Apple TV, Amazon updated the Fire TV and released the Fire TV Stick, and Google updated it's Chromecast device line.

HBO started providing À la carte access but I'd like to see the same from ESPN, ABC, CBS, NBC, and FOX (outside of Hulu).

Phones/Tablets

Phones in the past year have been lackluster in my opinion. On the Android side I haven't seen anything that makes me excited. Google's Nexus 6P and 5X were annouced with support for Marshmellow but they're pretty boring. Apple has decided to actually listen to the market and released a phablet in their iPhone 6+. Windows phone continues to be irrelevant and Blackberry continues to amaze me that they still exist given they don't appear to have any solid direction or plans to recapture the market.

Tablets have also been lackluster in my opinion. It was nice to see Amazon release a sub $100 tablet ($50!!!) as I really think that the market for tablets is going to be in that price point. The tablet isn't going to replace the laptop (the Microsoft Surface has proven that) and so the use case for tablets seems to be streaming media, playing games, and reading books. I think there will be a market for the iPad Pro amongst designers and architects, but I don't see it being anything that rejuvenates the tablet industry.

Home

Amazon released the Echo which, IMO, has been some of the best innovation in the at home arena. They've made it even better by providing both an Alexa SDK and a Skills Kit. One thing that's kept me from using Google Now on my Android phone has been the lock-in and the fact that it's only really useful when tied in with other Google owned services like GMail and Google Calendar. Having an SDK and Skills Kit allows ANY 3rd party to integrate with Alexa, and that's really awesome.

What would I like to see in the next year?

I'd like to see someone build something really interesting in the Phone market. I'd like to see it built on something other than Android or iOS. I'd also like to see it work out of the box with all the major DAV standards. Firefox OS or Ubuntu could achieve this with a good hardware partnership. Microsoft could do it to if they really wanted.

I'd like to see better cross device awareness for things like email, calendar, text messaging, and other notifications. Being able to act on a notification shouldn't be dependent on platform. Likewise, dismissing a notification on one device should be reflected on all devices, regardless of platform.

From the smartwatch category I'd like to see video chat, native SMS, longer battery life, better location awareness, and touch (specific to Pebble).

The Awesomeness of Owncloud

As I mentioned in my previous post, I've been using Owncloud for several years now. It's been a phenomenal way to control my own data and decouple myself from 3rd party services that change over time. Here's four reasons I use and love Owncloud.

It supports CardDav

This in and of itself would be reason enough to run Owncloud. There are CardDav clients that run on Android, iOS, OS X, Linux, and Windows. Which means you can access your contacts from anywhere, without having to export/import them every time you change your email client or cell phone carrier.

It supports CalDav

Like CardDav, support for CalDav allows you to access your calendar from almost any device. Owncloud also supports shared calendars, which is really useful for families as you can add shared events for everyone to access.

It supports WebDav

I'm going to sound like a broken record, but WebDav support allows you to access your files from almost any device. The web interface allows you to upload and download files even on a shared computer. My wife and I use this all the time to share our photos with each other, family, and friends. We also put all of our music and movies on our server so that we can access it from anywhere. 

It has native sync clients

You can install a native app on your mobile devices or desktop and have owncloud sync your files for you automatically. This allows you to not only share your files across all your devices but you now also have an automatic backup of your data. I've benefited from this several times as I've switched phones over the years as well as when I've switched laptops.

A decade and a half with open source

Over the last 15 years I've been trying to move away from relying on 3rd parties for critical services I use. It started out as a way to learn what standards existed and how they worked in practice. It's one thing to intellectually know what's there, but a whole other thing to use what's there in your everyday life.

In 1999 I started with my own web server, rather than relying on a 3rd party host (like Geocities). I bought a decent desktop computer and installed Slackware and Apache httpd. This has been crucial in my career growth as it allowed me to learn new web technologies as they've come out.

In the early 2000's I decided to run my own mail server. I tried out several and finally landed on qmail. It worked well on Slackware and it supports SMTP Auth. I added IMAP support using Courier IMAP. But I've since switched to Dovecot. qmail also supports integration with SpamAssassin for SPAM detection and filtering. 

In the mid/late 2000's I heard about a new web based mail client called RoundCube. It supported drag and drop like a native email client and I was hooked because it allowed me to remotely access my email with a feature rich client similar to what I had been using via native clients. In the last several years it's added support for plugins which have brought CardDav and CalDav integration.

In 2007 I built my own RSS aggregator (which I have since open sourced) as a way to learn Ruby on Rails. This has been the single greatest learning tool for me. Every time I want to learn a new language or platform I write a client for my aggregator. Google's decommissioning of it's rss client had zero affect on me :)

About four years ago I decided to move from running my services on a standalone desktop box to running them on a server in my own cloud. The big reason is that I needed a server that I could tinker on that won't affect my email, calendar, contact, and file access. So I built my own server and installed XenServer. This has allowed me spin-up and play while also keeping my critical services running rock solid.

About 3 or 4 years ago I ran across Owncloud. I was looking for an alternative to Dropbox because I wasn't happy with Dropbox's model of having to use their software to access my files. Owncloud was revolutionary in allowing me to stop relying on 3rd party services for access to my critical data. After installing Owncloud I controlled my calendar, contacts, and files.

Sometime in the last 3 years I stumbled across GitLab, an open source alternative to Github.  I write a lot of software at home but much of it is very specific to things I want to do and aren't really interesting from an open-source perspective. GitLab allows me to work on private projects and access my source code using a remote git server. When something becomes useful to more than just myself I open source it. 

Learning to Lead: Accountability

In my previous post in the Learning to Lead series I talked about leaders needing to be motivators. In this post I'd like to talk about accountability.

Responsibility vs Accountability

As a leader you're often going to be the situation of being accountable while ultimately not responsible for a creating the solution. This is particularly true for managers where they're accountable for the delivery of a project or feature but not responsible for the implementation.

The danger of being accountable for something but not responsible is that you'll either end up micro-managing or under-managing those responsible for solving the problem. There's a really fine line between micro-management and under-management. One helpful phrase I've heard and used in my career is trust but verify. This means that you'll have to delegate to others and trust them relative to their experience and skill-set but verify that they're on the right track.

There are several helpful tools that can be used to practice trust but verify.

• Project burn-down reports
• Agile stories and tasks
• Architectural design documentation
• Daily scrum
• Demo day

Solving the correct problem

Being accountable means ensuring the team is solving the correct problem. This is easier in an agile environment as it's the product managers role in sprint planning to be the voice of the customer. But that doesn't ensure that during a sprint the team isn't randomized by outside work or out of band requests.

Accountability means being able to prioritize and make hard decisions on what the right thing to work on is. Often this means coordinating with both product, management, and other senior leadership to weigh the pro's and con's of new work that comes in.

One easy way to make accountability part of your teams culture is to practice it during your daily scrum. It's up to the engineering lead and other leaders to make sure that as people go through what they're working on today at stand-up that it's the most important work that needs to be completed. If someone says they're about to start something that's lower priority than some other work the team should be calling out the discrepancy and holding each other accountable to working on the correct stories/bugs.

Raising the red flag early

Another area of accountability that I'd like to call out is being willing to raise red flags early enough for them to be acted upon. In the technology industry we make a lot of decisions and set schedules based off of estimates. Once a project is set in motion it's often uncomfortable or unpopular to raise a red flag. As a leader though, you're accountable for the overall health of the project. If your estimates are incorrect or based on incomplete data it's important to raise the red flag as the project is ultimately unhealthy.

When raising this flag the accountable party should be able to explain why the flag is being raised, as well as what it would take to remove the red flag.

Learning to Lead: Motivating People To Solve a Problem

In my previous post in the Learning to Lead series I talked about how being able to facilitate a conversation is an important leadership quality. In this post I'd like to talk about motivation and how the ability to motivate sets great leaders apart from the rest of the pack.

Many people's first reaction to motivation is to think about compensation. While compensation is an important motivator, it's not the ultimate motivator. If you haven't already, go watch the surprising truth about what motivates us. It debunks the myth that money is the ultimate motivator and is a great introduction to the type of things that will motivate once money isn't a worry any more.

I truly believe that the ability to motivate is one of the things that truly sets great leaders apart. Being a good motivator is not about being a cheerleader or always being positive and perky. While those things are occasionally required, motivation is about so much more than your attitude or presentation. Motivation is about being able to call others to action. In the tech industry this is especially important because lack of motivation has a direct correlation to loss of productivity, slipped schedules, and quality code (i.e. buggy and/or unmaintainable).

In my experience as both a software development engineer and as an engineering manager, there are three key areas to focus on when trying to motivate individuals or a team.

Impact

Engineers should understand the impact of what they're working on. This comes in the form of understanding the short term, mid-term, and long term benefits to their customers and their team. They should have enough information to understand why their work is important and to empathize with those that need it to be completed. Most engineers thrive on knowing that their work is being used by other people. It's much the same as an musician being motivated by knowing that others are listening to their songs. Or an author being motivated by knowing that someone is lost in their narrative.

Interesting

This may sound obvious but the work that's being done should be interesting. If your engineers feel that what they're doing is busy work, repetitive, or monotonous they're not going to be motivated to complete it. In this case you need to learn to correlate the current work they're doing with something that is of interest to them. Often I've seen lack of interest when a team is in bug fixing mode or just about to ship a product. In this case it's important to emphasize how what they're working on now enables them to work on the next big thing.

Another way to help make the work interesting is to find a tie between it and their career development. Maybe it gives them exposure to a broader set of skills or technologies. Maybe it allows them to check a box on their career goals or will help prepare them for being promoted to the next level.

Relate

The engineer needs to personally relate to the problem in some way. The best way I've found to help engineers relate is by dogfooding their own software. Using their software everyday in their personal lives will help them see what others are experiencing. It will help them want to fix the pain points that otherwise wouldn't be important to them.

Learning to Lead: facilitating conversation

In my previous post in the Learning to Lead series I talked about how earned trust is the cornerstone to leadership. In this post I'd like to look at another aspect of a good leader; facilitating conversation. Being able to facilitate a conversation may not be at the forefront of the qualities you attribute to good leadership, but I think it should be. Being able to facilitate a conversation shows a level of maturity that's needed in order to lead people successfully.

Ensuring the purpose is known 

Every conversation has a purpose and I'm still surprised at how often I've seen two people arguing with each other simply on the basis of not having a shared understanding on what the purpose of the conversation is. A good conversation facilitator will be able to articulate in a meaningful way the purpose of the conversation. Often this can be accomplished by stating what the desire outcome is right at the beginning. For example, "Today we're here to talk about FOO and make a decision about BAR with regards to FOO."

Getting people to participate

One of the keys to being a good conversation facilitator is getting people to participate in the conversation. This can often be difficult for a variety of reasons like people being uncomfortable talking in large groups, not wanting to speak up, having a lack of confidence, being intimidated by their peers, and etc. A good leader is able to encourage participation in the conversation without it being awkward.

Some tips for conversation facilitation:

• Ask open ended questions. This discourages one word responses and encourages meaningful conversation.
• Don't be afraid to let the room be silent. Often people trying to facilitate conversation will talk and talk and talk so as to avoid silence. Not everyone is an off the cuff thinker. Silence allows people to process what they've just heard and formulate a response. The key is figuring out when it's been silent long enough the the conversation needs help.
• Recap. This is useful at the beginning of the conversation as well as the end. At the beginning of the conversation it's often helpful to recap what the goals of the conversation are. For example, "when we finish today we should have a plan of record for...". At the end of the conversation a recap is useful to make sure everyone heard the same thing.
• If you know someone is passionate about a particular topic but not eager to put forth their opinion, you can try to gently guide them into the conversation. This can be as simple as saying "Tom, you and I were talking about something similar the other day which makes me believe this is something of interest to you. I'd love to hear your opinion on ..."
• Be direct and ask someone else to respond to a particular comment or statement. This can be especially useful when someone is steam rolling the conversation. For example, "Harriet, what are your thoughts on what Bill just said? Do you agree or disagree that..."

Avoiding derailment

Tangents are unavoidable, especially if you've got any "talkers" in the group. But tangents don't have to derail the conversation. A good facilitator is able to keep the conversation on topic. One common reason a conversation gets derailed is if someone else has an agenda that's not part of the purpose of the conversation. A good facilitator is not afraid to steer the conversation back on topic. This can often be accomplished by saying "Jess, that's a great point but I'm not sure that this is the correct venue for it. Let's set aside some time specifically to talk about that so we can use this time to talk about ..."

Another way conversations can get derailed is if you've got someone that rambles. What I've often found is best is to tackle a rambler head on. You can do this by jumping in and saying "That's a great point Sue, I'm curious to hear what other people think about the topic as well." Occasionally you have to be blunt and say something like "Greg, the latter part of what you're saying isn't really pertinent to the conversation at hand, let's stick to this topic now and we can get back to the latter part of what you're saying at another time."

Learning to Lead: It Starts With Trust

In my previous post on being a Senior Software Engineer I talked about one of the characteristics that defines the role is being able to get people to want to follow you. At it's heart the problem is one of trust. People don't want to follow someone they don't trust. What does it take to gain trust? Fully answering that question would probably take a novel. But at a high level I believe there are five key aspects to earning the trust of others.

Honesty

Any conversation about trust needs to start with honesty. At it's core honesty is about NOT deceiving others. As a software engineer that means you're able to:

• Say I don't know when you don't have the answer.
• Remove personal bias when evaluating a solution. When you can't remove the bias, it means communicating that bias clearly.
• Give credit where it is due (i.e. don't take credit for others achievements).
• Publicly recognize the achievements of your team.
• Provide clear, constructive criticism when someone is not doing something well.

Integrity

Being a leader means having a known set of guiding principles that you hold yourself and others to. The key is that you hold yourself to them FIRST. It's also important that the value of these principles is understood by others. It helps if others agree with these principles, but even if they don't knowing that you're holding yourself to your own standard helps earns trust.

Respect

The key to gaining the respect of your peers is to start with respecting them. In the technology industry this means valuing others skills and abilities. Not just the skills and abilities that you find value in, but also the skills and abilities that THEY find value in. Respect involves holding others achievements in high esteem.

Transparency

In my opinion transparency as a leader in the technology industry is not about making sure everyone knows everything you know. That can actually be detrimental to the team. It can add unneeded stress on those that don't have the context or the maturity to deal with the information.

Instead transparency as a leader is about making your motivations known. Help people to understand why. Why you're asking them to do something, Why something is the correct priority. Why somethings not the right direction for the team or project.

Fallibility

The last key aspect to earning trust is being able to admit when you're wrong. Everyone is human and humans make mistakes. Being able to admit when you're wrong sets the tone that it's okay to acknowledge your humanity. Once you're able to admit you're wrong you can start to correct the problem.

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.

Agile Development: Sprint Retrospective

In my previous post in this Agile Development series I detailed the typical workflow for planning a sprint. In this post I will outline the process of the sprint retrospective. One helpful way to think about the sprint retrospective is as a mini postmortem. During the retrospective the team goes over what went well, what didn't go well, and what the team could have done better.

What Went Well

The reason we ask what went well is not so that we can pat each other on the back and inflate our egos. One of the keys to a successful agile project is consistency in the velocity of the team sprint over sprint. One of the best ways to do this is to identify what lead to success so that the team can capitalize on it in the upcoming sprint(s).

What Didn't Go Well

As with most growth being realistic, open and honest about our mistakes and failures leads to not repeating them. The purpose of identifying what didn't go well is NOT to lay blame on any particular person or people. Identifying what didn't go well helps us to avoid or correct them those mistakes.

What Could Be Done Better

At first this may not seem different from identifying what didn't go well. The real difference is that we recognize things that may have gone well but could have gone better. Asking what we could do better is an opportunity to identify gaps in our planning, our process, and our estimates. This question should lead directly to actions that can be taken to increase or maintain the teams current velocity.

Because the sprint review typically takes place before the planning of the next sprint asking these three questions provides the team with the opportunity to make changes that give them a higher likelihood for success before the next sprint starts.

Agile Development: Planning A Sprint

In my previous post in this Agile Development series I walked you through the daily stand-up. In this post I'll go outline the typical workflow for planning a sprint.

Identify The Features

The product owner, who is serving as the voice of the customer, proposes the highest priority features. The scrum team is responsible for getting clarification, pushing back on features, and proposing features or work that should be accomplished. Features should be prioritized based on their overall business value. It's important to note that working on tech debt can often provide down stream business value by enabling new feature work.

Prioritize and Estimate

Once the scrum team has identified the features to work on in the sprint, the team should then pull all of the stories associated with that feature into the sprint backlog. The product owner and scrum team should negotiate the priority of the stories. Once the priority of the stories has been determined the team needs to estimate the level of effort for each individual story.

One typical way of estimating stories during planning is to pick a story that does not have a lot of ambiguity which represents a medium (tee-shirt sized) amount of work. The team then assigns that story a point value (the middle value of their pointing system). The team then moves on to point the rest of the stories based on them being either more effort or less effort than the original story. Stories that are more effort are assigned a higher point value while stories with lower effort are assigned a lower point value.

Determine What Stories Make It Into The Sprint

Just because the product owner or scrum team has identified a feature (and it's related stories and bugs) as high priority doesn't mean that the team can actually complete that feature in a sprint. The team needs a way to estimate the amount of work that can be accomplished by the team during the sprint. This is typically done through velocity tracking.

Velocity in agile is typically determined by the amount of points the team was able to accomplish in the previous sprint. Historical sprints aren't to be taken into account as each sprint the teams goal is to get better and better as estimating the level of effort for story work.

The sprint backlog should only contain enough stories to meet the teams velocity. Choosing to few story points means that the team will likely have to poach more work (which hasn't been vetted) from the product backlog. Choosing too many story points means the team is not likely to finish all the work in the given sprint, setting the team up for failure from the start.

At first the teams velocity will be all over the place as they work out their estimation techniques. But over time the team should start to settle in to a consistent velocity. It's important to be aware that there are several common practices that can negatively affect a teams velocity. It's important for the sprint team to guard against these in order to accurately gauge their velocity sprint over sprint.

Under or over estimating the level of effort of a story

Often this is the result of ambiguity that is not resolved priority to planning. If the team doesn't have enough information to accurately gauge the level of effort for a particular story the product owner and scrum master should first work to resolve the ambiguities before a feature or story is considered for a sprint. This is an example of a valid reason for the sprint team to push back on a particular feature or story.

Unplanned sprint work or re-prioritization of the sprint deliverables mid-sprint

This is an Agile no-no and should be avoided at all costs. In Agile our sprint duration is typically short enough that when new work comes up we can prioritize it at the next sprint planning meeting. If new high priority work or re-prioritization mid-sprint is truely unavoidable the best way to make sure it doesn't impact the overall sprint deliverables is for the whole team to understand what the lowest priority work is and have that work drop out of the sprint.

Unaccounted for absence

People are going to take vacation, get sick, or be off for a holiday. It's difficult to account for sick time but it is very easy to account for holiday's and vacation time. Make sure in your sprint planning you understand how many days during the sprint people know they will be out and reduce that sprints velocity accordingly.

Other regular duties

Many software organizations use the DevOps model where the developer is on-call for the software and services they own. Not accounting for this type of work can have a negative impact on planning as the sprint team will sign-up for more work than they can actually accomplish.

Break The Stories down into tasks

Once the sprint backlog has been determined the team should break the stories down into smaller more granular tasks. This allows for more story work to be done in parallel. The team can swarm on a story together ensuring that the highest priority work is done first.

Once the tasks are identified the team is ready to start the sprint!

Agile Development: Stand-up

In my previous post in this Agile Development series I explained two ways to determine sprint duration. In this post I'll go into detail on what an agile stand-up typically looks like.

One thing you've heard me mention over and over in this series is that one of the primary goals of agile is to decrease the total time it takes to complete the feedback loop. One key way to accomplish this is with a daily stand-up.

In it's most basic form the stand-up is a time-boxed meeting (typically 15 minutes) where the scrum team gets together and answers three simple questions:

1. What did I do yesterday?
2. What am I going to do today?
3. What am I blocked on?

What Did I Do Yesterday?

In it's most basic form this question is intended to determine if progress was made towards the overall sprint goals. Knowing, as a team, what has already been accomplished helps the team formulate a plan for what needs to be accomplished over the next day.

I've seen this question often turn into a check-list of everything you did during the day. But it's important to keep in mind that your goal is not to provide an overview of everything you did. Instead, the purpose of this question is to make sure that others are aware of how much progress was made towards the work you committed to the day before. This is especially important when work items in the sprint are interdependent.

What Am I Going To Do Today?

There are two reasons that telling the team what you plan to accomplish for the day is important. First, it allows the team to validate whether the work is really the top priority for the sprint. During sprint planning many teams will prioritize the backlog for the sprint. But because our feedback loop is so short the priorities of any individual task may change throughout the sprint or even daily.

The second reason this question is important is that you are making a commitment to the team to accomplish a particular task. You can think of it as your daily contract with the team. And in turn the other members of the team are making a commitment to you to get other work done. This is how the team is able to increase and maintain a particular velocity. The team is able to time and coordinate work at a granular level that allows the team to maintain a constant throughput. 

What Am I Blocked On?

Making sure that the team is aware of any potentially blocking issues allows the team to react quicker and not allow blocking issues to affect the teams throughput. Because the scrum team talks about this daily, it is able to address potentially blocking or blocking issues immediately.

If a particular team member is blocked on a technical issue, I've often seen the scrum team swarm on the issue until it gets resolved. This has the benefit of making sure any blocking issue that is an upstream dependency of other sprint tasks gets resolved quickly and the team is able to dedicate more of the sprint to work that was planned.

If an issue cannot be resolved due to some unforeseen circumstance the sprint team has the ability to adjust and pull in additional tasks into the sprint while the blocking issue is being resolved. Because we talk about blocking issues daily, there shouldn't be a significant impact on the sprint schedule.

Parking Lots

It's often the case that during stand-up an issue comes up that requires a deeper dive than the 15 minutes allotted allows for. Fight the urge to go into detail during stand-up on the issue. Instead, announce that you have a parking lot and who should attend and then table the issue until after the stand-up is over. This allows less of the team to be randomized by an issue that isn't directly related to their daily commitment. 

Agile Development: Determining Sprint Duration

In my previous post in this Agile Development series I explained the anatomy of a sprint in terms of the three different sprint phases. In this post I'll detail the two main ways sprint duration is determined.

Fixed Time

Most sprint teams you come across will use a fixed time for their sprints. In my experience 2 to 3 week sprints are the most common duration. The goal of a fixed time sprint is to shorten the feedback loop with the customer in order to deliver the right features to them. By limiting the time to 2 or 3 weeks you can easily change course as the requirements change and provide continued business value to the customer without spending a lot of time on features that won't be used or whose requirements have changed.

Having a fixed time sprint allows the team to set expectations with your customer on what new features they will be building and when they will be available to the customer. I would strongly suggest that you don't have sprints that are longer than 3 weeks in duration. 2 to 3 weeks keeps the feedback loop small while also giving the sprint team enough time to build a feature out end to end. Increasing the amount of time it takes to complete the feedback loop means that the sprint team could spend more time building the wrong product and less time building the correct product should the requirements change.

It is occasionally the case with a fixed time sprint where the sprint will end and the team will have been unable to complete a particular feature. In this case the retrospective should identify the cause of the decreased velocity. Typical causes for a decrease in velocity (in my experience) have been:

• Failure to account for vacation or known leave of sprint team members.
• Failure to account for time spent on external work (like on-call duties).
• Failure to account for the unexpected work that grows the sprint backlog.
• Undefined or not well defined definitions of done.
• Stories that are too large and hide dependencies.
• Unknown external dependencies. 

Fixed Feature

Another, less common, way to determine sprint duration is to use a fixed feature approach. This approach says that a sprint is complete only when a particular feature is complete regardless of time. This is typically used when it is known that dependencies are hidden but that it is not easy to uncover those dependencies without first doing some work towards the end goal of the feature. In a system without a well defined or understood architecture, a fixed feature sprint duration is often used as it allows for the unknowns that go with the not well defined architecture.

Earlier in my career this was a more appealing way to determine sprint duration but as I've grown in my Agile planning I've come to realize that open-ended sprint duration's actually detract from shipping software more than they contribute to shipping complete software. Even with the most ambiguous problems it is usually better to first root out the ambiguity in a fixed time sprint and then plan and work on the feature.

Another reason that I've found for fixed feature sprints being less than ideal is that you have a harder time gauging your velocity as your velocity is determined by the amount of work you can complete in a fixed amount of time. Since knowing you're velocity is key for estimating when a feature is complete without it you cannot set your customers expectations as to when they will get a particular feature.

Fixed feature sprints also increase the time it takes to complete the feedback loop. And, as I mentioned earlier, increased feedback loops mean that it takes longer to respond to customer requests.