Tuesday, February 4, 2014

How to Idea? Be a Hunter.

I don't know about you but I've spent more years than I care to admit waiting for that 'great idea'.  Starting out, I figured I'd help my friends with their ideas until I had my own epiphany.  I worked my tail off and time passed.  I waited.  Ten years and several exits later I had a great resume and several wealthy friends, but still no idea of my own.  That wasn't the plan.  I was a smart guy.  I gave it a lot of thought and realized I had been like a hunter waiting for my quarry to shoot itself.  But that isn't how it works.

Now what?

"Ideas are easy" has become a mantra these days.  Execution is king.  It's true.  But the difference between a serviceable idea and a bad idea is like the difference between hitting the edge of the target and shooting in the opposite direction.  We've got to start somewhere so we should aim as wisely as we can.  For those of us for whom ideas do not immediately spring wholly formed like Athena from Zeus' forehead, what are we to do?  Take Athena's lead.  Be a hunter.

Look for the signs

Wait.  Watch.  Eventually you'll get the feeling you should look for.  Inconvenience.  You can notice it in someone else, but for passion/product fit it's a sensation that should be your own.  Inconvenience makes an excellent compass.  When you feel it head in that direction.  Ask "why?"  Ask that often enough and you'll get a glimpse of the beast you're looking to snare.  The idea won't yet be clear but the general outline of the problem should be apparent.

Be patient.  Understand before acting.

So you've been on the hunt for some time.  You've spotted something of interest.  Do you immediately spring into action?  Sure - if you haven't a care for the cost.  Tackling something as soon as we spot it often feels right because our instincts evolved on the savanna.  Hackathons and the like encourage this mentality.  The projects that emerge are often novel but are risky as the foundation of a business.  Attempting to build a solution before you have a deep understanding of a problem is like a hunter leaping on the back of the first thing that moves.  If you're lucky it's dinner but it could just as easily make dinner of you.  Be patient.  After that first hint you are on to something give yourself time to explore the problem you have discovered.  Like the hunters of old it may be necessary to track your prey for some time before finding just the right way to move in for the kill.

When to move?

At this stage some let analysis paralysis stop them dead in their tracks.  Don't panic.  You've cornered your prey so press the advantage.  But when to strike?  When you have validation.  Your passion for the problem is a good gauge.  If you can't stop thinking about the problem you're on to something.  You can also validate your choice by checking to make sure other players are attempting a solution but where you feel your idea solves the problem significantly better, faster, cheaper, etc.  If nobody else is trying to solve your problem you're either a clever first mover or a fool.  So tread carefully.  There are many ways to come at this, but it's important to validate.  Be creative, but find something that works.

In my case I chose to validate my approach to the process instead.   I started making predictions.  I figured if I could write one elevator pitch per week, if the ideas were any good sooner or later I should see them show up as funded companies. It was hard at first, but it got easier.  I started having more than one idea per week and could sift through the rubbish.  I watched and waited.  I was busy with another startup so the waiting was easy.  It didn't take long.  In six months I got my first hit. It was an article announcing a seed round funding one of the first ideas I'd logged.  Eighteen months passed and three quarters of the ideas hit as seeded companies.  I felt foolish for not doing this sooner.  I'd been having big ideas all along.  I just didn't bother to catch them.

Attack!

Everybody has great ideas but few stop to take them seriously.  When inspiration strikes and an idea appears in the mind, they dismiss it as unattainable or trivial.  To quote Tim Westergren, founder of Pandora, "Be sure to 'notice' ideas when you have them.  Stop.  Take the time to consider them seriously." Set aside the time and make it happen.  Once you've got the idea do your research.  Track your prey.  Understand it thoroughly.  Then validate your approach.  If the idea still has its hooks in you, pounce on it.

Make a choice.  It's time to act.  The next big idea is out there and it's yours for the taking.  Ready your bow and let Athena's arrow fly.

Wednesday, January 15, 2014

Remote Control

Twenty years ago the internet was still a research project where most people didn't have email and the idea of real-time video was the fantasy of porn addicts wishing for something better than usenet. Now gigabit fiber to your home is a thing and we all have wireless supercomputers masquerading as cellphones on our hips. It should come as no surprise then that the nature of work and how it gets done is changing. Remote work is a viable option for many despite the resistance of some. I'm not here to insist that you use remotes but I am saying, if you adapt your processes and how you communicate so remotes could work well, you'll outperform companies that can't. Here's why...

Better onboarding


On-boarding is where a lot of companies drop the ball. With everyone under one roof you get a lot of it for free so it's easy to convince yourself you're doing it right. If you have gaps in your onboarding or have no formal process at all, your remotes will be culturally disengaged, and much slower to learn your architecture. You might also have trouble gauging their progress ramping up and it's likely they'll feel lost to some degree. Reality check. Your in-office new hires have the same problems but are able to mitigate your lack of support through osmosis. It's a coincidence of geography that your in-office hires aren't performing as badly.  With remotes you have to be deliberate because your deficiencies are exaggerated. Get it together.

Better processes

Do the developers on your team have to tug at someone's elbow to get code reviewed? To have the code tested? To coordinate a build? To publish a release? If your development and deployment processes require your communication to be synchronous you're going to end up with a thousand little inefficiencies with frequent blocking as people wrestle for each others time. Because the waiting is brief this is easy to overlook. Each interruption also disrupts flow causing you to lose at least half an hour per day in lost productivity. With everybody in the same space, interrupting Bob once a day to do x may not seem like a big deal, but multiply that across each work day all year long. Add in remotes and watch the problem explode.  

We did the math at our own company. Manual pushes to production were costing us three man-weeks per year on a four person Dev team. That's an enormous opportunity cost. But there was hope. The initial estimate to fully automate our test and deploy process was only four man-weeks. Given that we'd gain what we lost in the first year alone it was a no-brainer. But we didn't stop there. We found the guys at sprint.ly had some great posts on Asynchronous development. It's a natural progression from the branch-per-feature approach. We didn't go completely asynchronous, but we did cut out most everything else: meetings and hand-off-wise, saving additional weeks of Dev time annually.

Better communication

The biggest challenge is making sure people are talking.  This isn't unique to remote working but it's the one challenge managing people that is the most exaggerated by it.  Worst case, a remote could spend weeks wasting the company's time surfing Youtube for cat videos. Conversely they could be a rockstar and you'd have no idea.  

Communication should be easy, often, and light weight - stand-ups are a good start, but make as much of it asynchronous as possible.  Make your expectations clear so you both know what success and failure look like.  You can establish these collaboratively but they should be documented and clearly defined.  Is the remote under performing?  They should know without having to ask you.  Are they excelling and the business is pleased with their performance? This should be crystal clear, not in some distant quarterly review, but continuously, because of the team's definition of success. 

I’m not a fan of meetings - I prefer to maximize flow - but I like to make sure we’re having the meetings we need to have.  About now you should be thinking, hey, those things sound good regardless of whether we have remotes.  Good.  That's the point.

Test, test, and then test again

If you're a business that is interested in trying remotes for the first time, run a few tests with existing employees. Tweak the knobs and experiment to see what works. I would suggest that for anything new you are trying whether it's a business process, remotes, a new product, whatever. You want to give yourself an opportunity to try things out in short runs so you can change things quickly if they don't work.

Why do people resist remote working? Because nobody got fired for not allowing it. It’s easy to say no because there’s no perceived risk in it. It feels safe. I would argue, though, that if you aren't able to support remotes, your company isn't as healthy as one who can. And that is a problem. If this describes your organization, explore why. I guarantee you you'll find something you can improve.  

For a full interview with me on the topic check out this link here. You can also check out more material from my interviewer Lisette Sutherland here as well. Enjoy!

Sunday, January 5, 2014

Spot me

If you've ever done any weight training you understand the importance of a spotter. You're slinging heavy weights around and to get the reps in without dropping dumbbells on your face you need someone to keep an eye on you. You can ask some stranger nearby for some help. That will at least keep you out of the hospital, but what do you do when you want validation that your approach is sound? What do you do when you plateau and need advice? What do you do when you're frustrated and need encouragement?

You need more than a spotter. You need a coach.

Professional development is no different. There have been many articles written about the need for coaches, mentors and accountability partners. Call them what you will. We'll stick with the term coach for the sake of the metaphor. If you haven't got one already. Stop now. Read this, this, this, and this. Then come back here. My point is to challenge you to get more out of this relationship than you already have.  

Now you've found a coach. Maybe you talk once a week. Maybe you get some advice that occasionally makes a difference. If that's how it feels, you can do better. Much better.  Based on my own experience as well as conversations with serial entrepreneurs I can say this with certainty - If you're starting a company or are involved with a start-up the urgency to get high performance feedback cannot be overstated.  

If you want to achieve growth whether it's personal or professional you should be having "Aha!" moments. If you're on the same level with your coach the exchange can go both ways. The point is you should view your sessions like exercises for a body builder. They should push you outside of your comfort zone. They should challenge you. Not sometimes, but most of the time. Also, read. A lot. Talks with your partner don't have to be like a book club but if you aren't regularly exposing yourself to new ideas, you're denying yourself the leaps in perspective that approach can provide.

It's also possible that you were once excited but things have waned. It's tough when you've had a long stretch of success with someone and that shared history makes it hard to let go. Don't be afraid to find another coach if the fire has gone out. This is a mentor or accountability partner, not a marriage. If your coach isn't regularly challenging you and pushing you toward your career and life goals it's time to move on. Don't delay. Keep moving. Your career will thank you.

Lastly, the two of you should be measuring and recognizing progress. This is easiest if you're running a startup or a business unit because there are usually textbook metrics to consider. It gets more challenging the further afield you get from those roles, but don't think that means you can ignore their importance. Just like reps in a workout, if you're not measuring anything there is no way to gauge progress and the whole effort devolves into an exercise in vanity.

If your mentor is just a spotter find another. When you choose well they can help you manage your weak spots so you can push yourself harder and farther than you thought possible. They help keep you consistent. They challenge you, but also act as a safety net.  You don't want to spend time with someone that isn't proactively working with you to help you achieve your goals. You should dig until you find someone that excites you; that changes you. The time spent with them shouldn't just be rewarding. It should be transformative.

Saturday, December 21, 2013

QA is Dead. Long live QA!

This isn't specific to startups but it still applies.  I was recently asked for advice on how to go from two week sprints to one.  The conversation was one I've had several times.

Client: "We are a scrum shop that has two week sprints.  We'd like to release faster.  Any suggestions?"
Me: "Do you have a QA handoff during the sprint?"
Client: "Sure.  We basically do waterfall during the sprint."
Me: "I've got it!"
Client: "Great!"
Me: "Fire your testers."
Client: "..."

I'm only half joking.  

I used to think having a QA person was the essential fourth technical hire, adding more as needed as the organization grew.  For close to ten years that's how I'd managed teams, ensuring each team had access to at least one.  That changed last year.  We were pushing for faster and faster releases with a client and something didn't feel right.  As it happens we were having trouble keeping our QA role filled, the problem wreaking havoc with our release schedule.  It needed to stop.    

We held a series of meetings to discuss our needs and what could be done to address them.  We all agreed we needed tests.  We all agreed we needed someone to own testing.  We also agreed that devs should own unit tests, but the question of if or how much in the way of integration testing they should do was a matter of intense debate.  Should we have a QA that only does spot testing?  Should a human ever repeat a test by hand?  Should we forgo human testing and instead have a QA Engineer that was chiefly a programmer?  If so how could we cleanly divide their work from the other engineers?

It was a lot to process.  During this time we plowed through countless testing resources, books, blogs, and tweets.  We hit the jackpot when we ran into How Google Tests Software, a great book on how testing evolved during the early days at the Goog and it gave us the answers we were looking for.  The sky opened.  We had been looking at QA all wrong.

I'm paraphrasing, but the problem is essentially in thinking that any part of QA is somebody else's job.  We weren't so far gone to think that engineers didn't own any of it it but we certainly weren't owning enough.  Engineers write a few unit tests and figure that's it.  Managers jam a QA person between the engineers and each release and call their job done.  The reality is if you want to avoid waterfalls entirely you've got to bake your testing completely into your code effort - not some of the tests, but all of them.  The code isn't done until the testing is.

We were initially skeptical at first.  I mean when you're used to seeing a net below you when you cross the high wire it's a little unnerving when it's gone, right?  Once we realized that having devs own the whole process meant the wire was actually a bridge there was no fear.  The need for a safety net was an illusion perpetuated by our own bad behavior.

How do you know when you've done it right?  You won't need any testers.  Having a tester from the get go creates an artificial dependence on someone else to do your testing for you. It also creates an unnecessary step in your release process. Be your own tester first. Separate QA roles should only exist once your QA needs involve a strategic planning component that can no longer be distributed throughout the development team.  It depends somewhat on your dev team and your product, but for most places this isn't until the third or fourth year.

Do the work yourself.  Design a workflow that requires developers to wipe their own behinds, by writing automated tests for and testing their own code.  Your devs make smarter decisions.  You can stop paying for people you don’t need.  You can finally get the waterfall out of your scrum.  I would go so far as to suggest that Continuous Delivery can't be achieved without this approach.  You can do without dedicated QA.  Start now.  Your code, your process, your developers, your timeline, and your budget will thank you for it.

Monday, December 9, 2013

Joe's Rule

Nobody likes to be in debt, but money and time are scarce when you're getting started, and whether it's student loans or technical debt most of us have a hole to climb out of. You can ignore it but debt is a beast which feeds on inattention. The challenge for a start-up is that even when you're paying attention it's hard to know how to prioritize the debts you're facing.  When a client's team was struggling for yet another week to determine which tickets on the backlog were the most important I was determined to help them find a way through.  

Conversationally the problem seemed simple. Pick the tasks that provided the most value. But in practice it is much more challenging. What is value? Value to who? How to define it? How do you explain it? What's valuable to engineering may not be valuable to the business. We needed a simple definition that we could all agree on.

One difficulty is that engineers struggle to prioritize technically interesting problems over tasks that provide business-facing value.  It’s natural.  Don’t deny it.  When I'm wearing my developer hat I do it too. The other challenge is that when you care about code every refactor feels important. So how do you decide?

Time for some soul searching. I had recently read First Fire All the Managers, a piece on flat management and intrinsic motivators. It argued that the way to get the best out of your people was to make them all managers. While chewing on that it occurred to me. Take it one step further. What if everyone was an owner or investor? Typical investors won't even talk about something unless the return is at least 3x the intial investment, so why should we? What are we investing? Time.

The currency in engineering is time but devs don’t usually consider ROI on time concretely when prioritizing.  So I took this back to the client, "Don't do anything that doesn't have at least a 3x return. Prioritize what remains by what provides the greatest return in time or dollars for that time." In our next meeting I suggested each engineer put on an investor hat and to prioritize tasks accordingly. I was optimistic but even I was surprised by how well this was received. The payoff was immediate.  Priorities ceased to be arbitrary. Many tasks ceased to be relevant at all. It changed the context of everything we were doing, from the way we approached what to refactor, to whether we wrote tests at all. Discussions of refactors with the business became much more productive and challenges we had in defending to the business what technical debt we needed to pay off and when fell away.  Having a concrete threshold made all the difference.

This spread quickly from a way to deal with technical debt to how we approached looking at everything they did as an engineering team. The irony is that despite having introduced the rule myself it was easy to forget. Joe, one of the lead developers, took it up as his banner and became its consistent champion. Time and time again it cut debates short about what to do next, and saved them on many occasions from sinking effort in to tasks without sufficient value. It's become a permanent tool in my belt and I have Joe to thank for that. Here's to you Joe.

Tuesday, May 28, 2013

The Caffeine God

Years ago we dropped out of college and started a game company.  We set deadlines for our first release and hit them more or less.  The game was a moderate success.  Excited by our success our publisher secured a license to the alpha code for the DOOM engine before anyone else and convinced us to write a shooter with it.  Never mind that we weren't really interested in shooters.  Had no experience with shooters.  Sure we could do it!  To make matters worse the engine was dated and for the game to turn a profit we had to beat a major studio with a triple A title to market for our venture to be profitable.  Keep in mind we were just two guys working out of my friend's parent's house.  Did I mention we were only getting 3000 a month to develop this thing?  Our publisher chose a release date and the grind began.


To any sane person it would have been obvious our goal was impossible.  We had no real budget.  We were only two guys (four by the end).  The engine was buggy.  It was incomplete.  It was clearly an unfinished experiment, rather than an actual game engine.  Our initial milestones came and went.  The publisher ratcheted up the pressure.  We were young and stupid and refused to admit to reality so we soldiered on.  In reaction to the mounting pressure we worked longer and longer hours.  Eventually we stopped sleeping altogether. Caffeine made this possible.


High doses of caffeine make you strange.  Anyone in the game biz can attest to this.  We've all spent weeks or months at a time overdosing daily on the stuff to keep the wheels of the industry turning.  40 hour days are not uncommon.  After doing this for a couple of months we started noticing something.  In the wee hours of the night when one of us was alone we kept thinking there was someone else in the room.  At first we thought it was one of the other developers.  It soon became clear however that it was an imaginary presence brought on by the paranoia from the caffeine.  It was very unsettling.  But then we got used to it.  And eventually began to talk to it.  We would ask it questions.  We'd ask it to look at this or that thing as we completed parts of the game.  Toward the end we were leaving it offerings of food and drink - usually pizza and mountain dew.  Religions start this way.

The game was finally released.  A year late.  The buzz around the engine was gone.  Our savings were gone.  Our patience was gone.  At least the game was finished.  It was over.  We released a commercial game on a budget of only 30,000 dollars in 24 months that was intended to compete with Duke Nuke 'em.  It was an abysmal failure. When it was all over and I was finally able to stop drinking so much caffeine I felt a profound sense of loss.  Not only had our dream of starting a successful game company been shattered but the presence was gone.  Our long time invisible friend had vanished.

Tuesday, November 20, 2012

Translating an Epic

What do the story of Gilgamesh, the Iliad, and the Mahābhārata have in common with your project document?  They are epics that have been translated through multiple ‘languages’ and been touched by many hands during translation.  I point out these similarities because we have found the metaphor of translation of historical epics useful in describing the various stages that our own project epics undergo as they are translated.  

Your next project document is no different.

In scrum-speak user stories are the single sentence descriptions product owners (POs) use to describe their needs.  Since we refer to these descriptions as stories it is natural that we call large collections of these stories epics.  POs write the epics and pass them to the dev team in some fashion, the message changing, and changing hands multiple times.  Multiple teams.  Multiple people.  Multiple translations.  

I say ‘translations’ because intentions are easily miscommunicated and when combined with the differences in how biz and dev describe the world it can often feel like we’re speaking completely different languages.  In considering how to manage these translations we explored a number of metaphors.  It needed to convey the importance of the POs original request while providing enough layers of translation to contain all the times the message would change hands.  After considering and discarding several we settled on the Biblical.  I present this to you in the hope that it or some variation may be as useful to you as it has been for us.  


As you read this keep in mind that we use one-week sprints and the Atlassian On-Demand tools.

HEBREW

The raw original epic from the PO.  It has no estimates. It could very possibly make no sense.  But it does convey intent and intends to paint a picture of how users will interact with new/updated features.

  • Written by the PO.
  • Can be delivered through any channel (word doc, wiki, etc), but must be committed to the wiki in it's own epic page before the Greek translation can begin.
  • May include prototypes or flowcharts that live elsewhere, including the backs of napkins.


GREEK

The first translation digestible by developers translated by developers from the original Hebrew.  It is much more coherent and sprint friendly than the Hebrew.

  • Written by a developer.
  • Is probably in the proper story format, but...
  • Stories may not be small enough to fit in a sprint.
  • Lives in the wiki.
  • Is written after the Hebrew on the same wiki page.


LATIN

An in-place translation of the Greek which is sufficiently granular and organized to determine the delivery date for the epic

  • Written collaboratively by the developers.
  • Is written over the Greek in the same wiki page.
  • Contains only stories that are small enough to fit in a sprint.
  • Lives in the wiki.
  • Finalizing the Latin involves a dev team round table.  Prior to this round table, each member separately writes estimates for each story in the Greek, if necessary breaking stories down into 3-day or smaller stories in the process.  At the round table, the different breakdowns and time estimates are reconciled.  In general the longest estimate wins.
  • Estimate totals are used to determine a delivery date based on 4 development days (32 development hours) per developer per 5-day work week.
  • The final result of this effort is to be confirmed by the PO as still representative of the original intent.


ENGLISH

The first official translation that ends up in Jira.  It's in the proper format. It's actionable.  It includes test criteria. It has been approved by the PO.

  • Written by a developer.
  • Is written/created in JIRA.
  • Each story from the Latin is a story type ticket in JIRA.
  • Tickets are labeled with a version number or name of the epic.
  • No ticket may have an estimate longer than 3 days (given one week sprints).
  • If a ticket/story estimate ends up longer than 3 days the story must be broken down into two or more stories.
  • Tickets are grouped by upcoming sprints to uncover any problems with the deadline determined by the Latin translation.
  • Story acceptance criteria are not required until the Sprint Commit meeting and should be written by the team during the Sprint Prep meetings.

This works well for us. YMMV.  This is intended to spark discussion.  I’m interested to see what the rest of you out there are doing and how this maps to what you already have in place. Hit me up and let me know.