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.

Getting To The Next Level

Over the several years I've spent a lot of time mentoring, managing, and leading teams. For most of my career I was unclear what it meant to get to the next level. I thought that as long as I did a good job I would be recognized for my accomplishments in the form of career advancement.

While my career has advanced well, I missed several opportunities to move up simply because I was unaware of what it took to get to the next level. So here are some helpful tips that you can use to advance your career.

Make it known you want to be there

This sounds obvious, but you'd be surprised at how many people never let their bosses know they're looking to move up the career ladder. In the fast paced world we live in, you're not going to get something unless you ask for it. Taking this step is pretty simple. It just requires the courage to say you want it.

Identify Your Gaps

This is more difficult. Not because it's hard to figure out where we need to grow, but because it's hard to hear that we do need to grow. Even the most self-aware people I know can tend to gloss over the areas they need to grow in. When you sit down with your manager to let them know you want to get to the next level ask them these two questions:

What am I doing now that I need to stop doing?
What am I not doing now that I need to start doing?

Take the Opportunities presented to you

Getting to the next level is not just about skill. It's also about taking advantage of the opportunities presented to you and applying your skill, or learning new skills. The latter is more important because most likely, you need to learn a lot in order to start functioning at the next level. Every opportunity you take gives you a chance to both learn new skills and hone the skills you already have.

Look for opportunities that will stretch you in an area you're not comfortable with.

Be a Mentor

The best way to learn something is to try to teach it. You'll learn where the gaps are in your knowledge or skill set very quickly. A great way to do this is to start mentoring others. You'll be asked lots of questions you have no idea how to answer. But you then have an opportunity to get to the right answer and learn a new skill or some new knowledge along the way.

Get a Mentor

Having a mentor who is at or above the level you're trying to achieve is important. Having already achieved the thing you're trying to achieve makes them a good resource for you. Ask them that their hurdles were to getting to that level. Ask them what areas you should focus on and how to practice working at that level. Talk through situations and opportunities you currently have and see how they would respond or lead.

Most importantly listen. Being mentored isn't about showing the mentor how much you already know. It's about being humble enough to be teachable.

The Unlearning Of Technology

I grew up in the Washington D.C. area. I grew up a Redskins fan (whose name I DO believe should be changed). That also meant I grew up hating the Cowboys. My family (and extended family) had season tickets and I could go to 2 - 8 games a year. When not at the games I would watch them at home. I was almost religious in my dedication. I could tell you the names of almost every starter and a good portion of the bench.

I moved to Seattle 10 years ago and now I couldn't name 5 people who play for the Redskins. I'm not quite as fanatic a Seahawks fan as I was a Redskins fan, but I watch every game, go to as many as I can, and can tell you their record, their standing in the league and who the key players are.

Did I set out to become a Seahawks fan and not a Redskins fan? No, I just like football and fell pray to convenience and repetition. Not having Redskins games readily available made it hard to stay up with the current happenings. Not watching games each week I wasn't able to learn what the team was doing well today, learning where their defense was weak and their offense strong. Essentially, I was spending time unlearning what I knew about the Redskins.

The same is true in the software industry. You're only going to know the ins and outs of platforms, frameworks, and code that you actually spend time with. If you don't spend time with it you'll evolve and change on separate paths.

Given enough time, eventually you'll grow apart from the technology. You'll stop recognizing the subtle changes from version to version. You'll stop being able to speak to the differentiation of the platform or framework. You'll make stupid, or novice mistakes when you do dive in. You'll miss important aspects of design, architecture, or code quality.

This isn't always a bad thing. Sometime, in order to learn something new, you need to unlearn something you knew well. But it's important to recognize that if you're not actively learning and growing with a platform, framework, or code base, then you're actively unlearning it.

What are you un-learning today that you shouldn't be?

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.

How do you deal with adversity in the workplace?

You spend a lot of time at work. In fact you're spending around 2000 hours a year if you're full time. In that 2000 hours it's inevitable that you're going to work on a project you don't like, work with people you don't get along with, or be asked to do something you think is the wrong thing to do. You're likely going to have to deal with one or more of these several times a year.

What do you do when one of those situations happens? Do you get pissed off and act out? Do you become the negative person in the office always being a contrarian? Do you villainize someone associated with the decision? Or are you someone who sees adversity as a growth opportunity?

If you aren't approaching work place adversity as a growth opportunity, you're missing out on valuable experience that you will need to be successful in not only your career, but in life in general.

So what can we learn from the adversity we face?

Sometimes we have to choose from the lesser or two evils

You're not going to find a way to win in every situation. Often you're going to be presented with lose/lose situations where your goal is going to be to find the solution that has the least negative outcome. Learning to do this will help you come out ahead in the long run, and can help you avoid lose/lose situations in the future by helping you to prepare for them before you encounter them.

You learn to see things from another persons point of view

In order to successfully deal with adversity that comes from interacting with others, you'll need to learn to see their point of view. That doesn't mean you need to learn to agree with them. It means that you need to be able to understand *why* they feel, act, or say what they do. Once you're able to learn this, you can then start to better communicate with them in a language that they understand. Helping others understand that they're heard is a giant step towards moving past interpersonal adversity.

You may learn that you're the source

This is the most important one in my opinion. In trying to deal with adversity head on, you may just learn that you're the source of whatever is wrong. If this is the case, realizing it gives you the opportunity to stop doing whatever you're doing that's causing the strain.

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!

The good and the bad of a Chrome OS/Android merge

Recently there have been reports of Google planning to merge Chrome OS and Android. I've been a Chrome OS user for 3 years (got a Pixel at Google I/O and have been loving it) and an Android user for 5 years. So I feel like I understand both operating systems very well.

My hope is that Google will take the best of both worlds and make something better. So in order to help facilitate that, here's my high level best/worst lists for each.

[update: 12/19/2015]: Russian translation available here thanks to Vlad!

What Chrome OS Does Well

Simplicity: Chrome OS is simple and intuitive. I would feel absolutely comfortable giving a chromebook to my mom or dad and be confident that they could surf the web and check their email without any problems.

Multiple Users: At first I didn't like that you had to log in to a Chromebook with a GMail account. But after using the Pixel for 3 years I think it makes things easier. My wife and I both share the Pixel and we do so with zero hassle. Logging in and out is fast and intuitive and there isn't an extra username/password that you have to remember. When friends come over and want to surf the web they can pick up the Pixel and start using it right away using their GMail account (and it seems almost everyone has one).

The Web: It should go without saying (but it won't) that an OS built on top of a browser should be good at surfing the web. And it is. Web based email works great. Streaming media like Netflix, Amazon Instant Video, and etc work great. Chrome OS just works when it comes to the web.

SSH: Surprisingly, Chrome OS's Secure Shell program works great and supports key based authentication. This makes using Chrome OS to work on servers simple and efficient.

Native Development Support: If you're a developer you can get shell access with crosh and use crouton to create a chroot to another flavor of Linux (like Ubuntu). Once you have a chroot setup you'll have access to the full suite of developer tools that Linux has to offer.

What Android Does Well

Niche Apps: I've come to rely on apps like KeePass, Owncloud, and Baby Connect in my day to day life. These apps go with me wherever I go and give me instant access to important information. Android is a very friendly environment for niche apps.

Mobile First Experiences: Instagram, Maps and Navigation (disclaimer, I work at Amazon on Maps), streaming media (these have web counterparts but they're lesser experiences than the mobile apps IMO because they're cluttered with display advertising), and a whole plethora of other apps that are built first for mobile and second for the web.

Games: While I'm not a big gamer, Android does games well. Games like Angry Birds, Fruit Ninja, Plants vs Zombies, Cut the Rope, Solitaire, Sudoku, and etc all run great and are fun on Android.

Contacts, Calendar, and Email: The native apps for contacts, email, and calendar work great, sync great, and are easy to use.

Switch to developer mode: Developer mode isn't turned on by default in Android. But it's really easy to enable. Just tap on the system version several times and you've unlocked the power of being a developer.

What Chrome OS Doesn't Do Well

Apps: Chrome is pretty horrible for apps. The HTML5 based apps I've used are clunky and not very functional.

Switch to developer mode: Switching to developer mode on Chrome OS is awful. It requires you to wipe your machine when switching in and out of developer mode. While booting up in developer mode you're presented with a terrible screen telling you that OS Verification is off. If you hit space bar you wipe the machine. Switching in and out of developer mode just isn't easy.

What Android Doesn't Do Well

The Web: The biggest concern I have with Android is that web surfing still sucks. So many sites still use flash or heavy javascript and just don't run well on Android. Web pages aren't optimized for small screens still (and probably won't ever really be). The web also wasn't made for touching but Android's primary input mechanism is touch.

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. 

Do network stations not care about being relevant

I'm a cable cutter. Not literally. I mean I don't go around the house looking for cables to cut, but I did drop cable T.V. a little more than 6.5 years ago. Not because I think TV is evil, and not because I wanted to be able to say I don't have cable (some people seem to be proud of that). But simply because I was bored of programmed television.

I found myself flipping through channels searching for something interesting to watch and never finding anything I was in the mood for. Or, even worse, finding something in the guide but having to sit through 15 minutes or 30 minutes of another show waiting for the show I wanted to come on.

At the time I was working on the video team at MSNBC working on streaming MSNBC content on the web and mobile devices. My wife and I were also starting to become more and more invested in the convenience of Netflix. Who wants to wait a day for a DVD when you can stream something immediately.

Netflix changed our viewing habits. For the first year or so Netflix streaming for us was about streaming full length movies. Basically an alternative to going out to the movies or to renting a DVD. But eventually we started using Netflix to primarily watching TV shows. I don't think I realized at the time but what I love about Netflix and other video streaming services like Amazon Instant Video is that I'm in control. I decide when and how much I want to watch.

Streaming video on-demand is about being in control of the content. Some days I may not have any time to watch anything, other days I may have enough time to watch a show or two, and sometimes (pre-kid) we'd spend an entire Saturday just relaxing and marathon watching a series.

On-demand video also makes me feel like I have more context between episodes. I'm actually more invested in the characters because I'm choosing to spend more time with them rather then being told when to spend that time (with a scheduled show that may or may not be convenient to my schedule).

All of this is to say that I think current TV programming is only good for live events. Programmed television was made for watching late night TV, Sports, the State of the Union, the debates, or even news. But the days of programmed television for a drame, sitcom, or any other series are over.

So why are the networks only streaming to current cable/satellite customers? It would seem to me that there'd be a whole market of folks just like me who'd be willing to pay $15 a month for on-demand access to network television shows (Hulu anyone?). It seems like the only way for places like NBC, CBS, and etc to complete in the new world order is for them to own their streams and to make them available à la carte.

Do network stations not care about being relevant? 

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.

Senior Software Engineer

One thing I've noticed throughout my career that's been pretty consistent is the desire of software engineers to be given the title Senior Software Engineer. I've seen many people claim the title without truly understanding what it means or what the role entails.

The Misnomer

Often I've seen people given the title or claim the title based on the number of years of experience they have or based on the fact that they have more technical chops than their peers. Being a senior software engineer doesn't have anything to do with years of experience, but instead is about maturity as an engineer. While the two may be correlated (highly so in many cases) there is not a causation relationship. I've seen just as many tenured developers who were no more senior than their counterparts fresh out of college. It's also not only about your technical ability (while that is a large part).

If years of experience don't define a senior engineer and being the most technical person doesn't then what does? In my opinion a senior engineer is someone who manifests most, if not all, of the following characteristics.

Language/Platform Agnostic

A senior software engineer may have language or platform preferences but they're able to deliver on any platform. This is because they understand system metaphors, abstractions, and compositions well enough to know how to learn what they don't know quickly. They identify the correct metaphors, abstractions, and compositions needed to be successful and realize that the syntax and libraries are just implementation details.  

Able to identify and articulate trade-offs

Building software is always about trade-offs. They are able to take schedule and scope into account when building a solution. They understand and are able to clearly articulate risks. For example, a senior engineer knows that with a fixed schedule scope must be variable. They're able to identify and clearly articulate what the proper scope is and what features are at risk.

They're about shipping software

First and foremost, a senior software engineer is able to deliver software. They deliver software in large volumes. This is largely to do with their ability to understand and quickly get through boilerplate code in order to focus on the real problems. They understand that unshipped software isn't making the business better.

Able to get people to want to follow them

Solving complex and ambiguous problems is a requirement of being a senior software engineer. But being able to solve those problems isn't sufficient for the title. A senior software engineer is able to successfully lead a team. They're able to motivate people to solve a problem, hold people accountable to solving the right problem, and get down to the level of other less experienced developers in order to stretch them and help them achieve goals that are beyond their current abilities. 

Able to simplify a complex problem

Senior software engineers are able to see through complex problems and break them down into smaller, easier to solve, problems.

Understand the correct amount of engineering required to solve the problem

Senior engineers don't over engineer solutions and likewise they don't under engineer solutions. They understand that software is meant to solve a particular set of problems while needing to stay maintainable in order to increase the lifespan and usefulness of the product. They recognize that the elegant solution is not always the correct solution. They also have the ability to take a complex problem and identify the potentially fragile portions of a solution and design around them without over generalizing a solution or making the solution less useful in solving the problem at hand.

They recognize that everything doesn't have to be "built here"

This one is pretty straight forward but difficult in practice. Senior engineers recognize when a particular problem is not part of the groups core competencies and look for external solutions. While a particular problem may be interesting, unique, or fun a senior software engineer is able to recognize when solving that problem in house doesn't add any business value or add burdensome tech debt. 

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.

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.

Agile Development: The Anatomy Of A Sprint

In my previous post in the Agile Development series I walked through the makeup of a sprint team. I explained the roles of Product, Dev, QA, Operations, and the Scrum Master. In this post I will go into detail on the anatomy of a sprint.

Planning

The first phase of the sprint life-cycle is planning. During the planning phase sprint velocity is determined, features are identified, features are estimated, and the backlog is created.

At it's most basic level the velocity of the sprint is determined by the number of points that were completed during the last sprint. When a sprint team first forms their velocity is very volatile. But as the team learns to estimate their story points more accurately there is less oscillation between the number of points completed sprint over sprint.

Determining which features are candidates for inclusion usually starts with product as the voice of the customer. Product will advocate for what the customer needs. The team will also identify what bugs and tech debt need to be addressed during the sprint.

Once the candidate features are identified the team will estimate the the level of effort for each story. At the formation of the sprint team a point system is determined and that point system is used for estimating work. The two most common point systems I've come across are using Fibonacci numbers (with 8 or 13 being the top end of a sprint) and using 1, 5, 10, 25, 50, and 100 as story points. Whatever your system of pointing there needs to be a way to determine small, medium and large stories.

There are many different estimating techniques but most teams I've seen use some sort of t-shirt size technique. They start by picking a story and assigning it an arbitrary point value. The rest of the stories are then pointed by determining if the story is larger or smaller than the initial story. When you have more than 3 assignments that you can use for point values you can get more granular and determine if the story is larger or smaller than the other stories in it's t-shirt size bucket.

Once the velocity is determined, potential features are identified, and stories are estimated you will be able to create your sprint backlog. Backlog creation begins by stack ranking the stories (taking dependencies into account) and cutting the sprint off after the last story that keeps the total number of sprint points at or less than the pre-determined sprint velocity.

Implementation

The second phase of the sprint life-cycle is implementation. During the implementation phase the team meets daily at stand-up and goes over what they worked on yesterday, what they're working on today, and any potential blocking issues. When a blocking issue is identified it's up to the scrum master to try to unblock the team member. During the implementation phase the software should be developed, tested, and integrated.

Review

The last phase of the sprint life-cycle is review. The review phase takes on two forms. The first is the sprint demo and the second is the sprint retrospective.

The sprint demo is the teams opportunity to showcase what they've built during the sprint. Sprint demos can actually be a very useful tool leading into the next sprint planning phase. Often when we think about planning with regards to software we think about what we're going to build from an architectural perspective. The problem with this line of thinking is that it typically leaves out integration, testing, and deployment. If we instead think about what we're going to demo during planning we'll have to take into account how we're going to demo it.

A note of caution about sprint demos. One mistake I've often seen teams make during sprint demos is to walk everyone through a bullet list of work that was performed. Walking others through a bullet list isn't a demo. If you find that your team is working on features that don't have a user facing component then figure out a creative way to tell the story of how what you worked on matters. Use an animation, a use case scenario, or maybe even a chart or some graphs to help illustrate what you worked on. 

The sprint retrospective is 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. The retrospective is a dedicated time for us to identify the issues that caused us to lose velocity, to call out our successes during the sprint, as well as identify what we could have done differently to have improved the sprint. Because the sprint review typically takes place before the planning of the next sprint we have an opportunity to make changes that give us a higher likelihood for success before the next sprint starts.

The retrospective IS NOT a finger pointing exercise. It's NOT a witch hunt or an opportunity to push blame around. The retrospective IS an opportunity to identify gaps in our planning, our process, or our estimates. The point of the retrospective is to maintain or increase our velocity.

Isn't there a phase missing?

You may be wondering where the "release" phase is. There isn't one. Releasing your software should be done as part of the implementation phase. Your sprint planning should account for what it takes to ship the software, if that's part of the definition of done for the sprint.