On Being Agile
First, some words from some smart guys:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
(from
agilemanifesto.org)
So, what's this all about? It's about being able to develop -- both applications and the business that they sit inside of -- in a way that's relevant to a white hot market and fickle consumers and customers.
Our CEO,
Mark looks at applications in terms of "jobs" -- that users hire applications to do a specific job. I think this is a wonderful analogy. One that I'll extend, and relative to my previous post, applications in today's world need to be like working for a startup. That job they have to do is going to change and need to pitch in doing other things. There's no way to do this with a traditional SDLC model, as far as development goes.
This is relevant because we've recently run across a few companies who have still been using such techniques, and they're finding it extremely hard to keep up with "the market" -- I still don't know what that means... but who does -- with 60 day build and QA cycles. I'm entirely unshocked. For me, if a feature's cycle is longer than 10 business days, it's not a feature, it's a project. A feature should be cycled in and out of development -- and put into a sandbox/showcase for users to test and QA for you -- in terms of hours/days, not weeks. Now, yes, I'm sure there's folks saying how there's cases that won't work. Clearly, if you have no sandbox and/or users, that doesn't work. But... it does! You have friends, peers, other coders, etc. If no one's testing this but you, not only with there be bugs, but you'll probably miss the usability issues that engineers tend to cause.
So... how's this relevant to business? Well, guess what, making strategic bets that you ride for 2 quarters without revisiting on a regular basis... that doesn't work anymore. At all. You need to be willing to adjust your focus and roadmap accordingly, or you're going to miss your mark and opportunity. Don't cause opportunity loss to the cry of "commitment to idea!" -- you have a core group of
principles as a company, stick to those. Everything else is/should be market, people and time driven.
Zone Coverage
This is somewhat more of a management-centric post, but it has some applicable theses for building apps and being an engineer in general.
Start-ups aren't about very, very specific tasks for specific people. They're really about having an 80% core competency, and a 20% zone skill that can cover for someone else. Unless you're the CTO/CIO/VPoE, then you're doing whatever you have to do to get things to fly. ;) Anyways, back to Zone. If you're an employee in a start-up, and you expect to code specific functionality 100% of the time, you're delusional. Maybe. It could be that the folk that hired you didn't make you aware of how these things go. I know, I know, it's hard to believe that there's an engineer worth his salt out there that hasn't been involved in a startup (/sarcasm off) but it's important to recognize this important fact. If you hire someone, and you tell them "Suzy, you're going to be a PHP engineer. I expect the best PHP out of you that you're capable of" and a week after starting, Suzy starts having to write copy because it's the necessary task of the day... Well, Suzy may not like you very much, and may slack on delivering on that -- albeit an extraordinarily important deliverable -- unbeknownst, to her, job. Now, if Suzy had been told up front, that part of her time was going to be spent "chipping in," or "helping out" with the rest of the team, there's a much higher chance that she's going to do her best to deliver what she can to help the team/company meet it's overall goals. It will also let her feel like she's a part of the overall business, not just the X lines of code she's expected to create on a daily basis.
This also comes down to who's got what skills. Guess what, I'm a pretty good writer. I'm not as good as our CEO -- not even close -- but I'm damn good. If he's swamped, I'll grab the ball and make sure it gets over the finish line if we have some document(s) that need to get out in a timely manner. Why? I'm the friggin' CTO, why should I write? Because my primary job -- just as any employee at a startup (or an established company, but that's a harder sell) -- is to
make the company succeed. Not help, not hope, not pray -- make. Same deal with Mark, same deal with Brent, all the way to Steve. We're all here to win. Granted, I'm terrible on the phone, so if there's a phone-centric task that may or may not involve me, that can be better accomplished by Brent -- who's amazing on the phone -- I have no problem handing that off to him. I know he's going to do a better job at it than I am.
So... how's this apply to you, Engineer Guy? Well... duh! Dependencies. Working in a team environment, as much as we'd all love things to move at the same pace, it's simply not going to happen. Throw a hand to that guy who's module really should have been spec'd an extra week. Or help the designer who might have Photoshop-block. Get yourself more involved in the blood and guts of the project you're working on. That kind of interest rubs off, and you may find your counterparts extending the same hand if you find your module overloading your days, too.
Content Form Factor - What are you trying to hit?
So I've been putting a big part of my "off time" braincycles into determining where our roadmap fits into the big picture of video -- or as our CEO has hammered into my head (and I wholeheartedly agree) -- this "Year of Internet Video" which I expect to extend beyond this year. I think I've come to somewhat of a thesis.
Video, as it sits, has two branches, form factors if you will. There's short clips -- segments, clips, quotes, "videobytes," etc. Then there's more traditional "show-length" form factors, these are generally 22 minutes, 44 minutes, or longer -- what you'd find from any typical old media content provider; broadcast network, cable network, movie studio, etc. Without question, we fall into the first form factor. More to the point, however, until there's a *real* consumer electronics convergence, i.e. I can hit a button on my remote (without having spent multiple hundreds or thousands of dollars on specialty equipment) -- the second form factor is simply not a reality.
When I'm at my computer, like the majority of users, I have a plethora of things going on, many of them requiring my attention, and most of those are non-entertainment related. When I *do* have a few minutes, I like to sneak in a few clips, or maybe a quick read of a blog, or sending/reading a few IMs. Quite frankly, I have far too much to do to watch a half hour -- or longer -- episodic saga. This reality has spawned a term (Webisode) which really speaks to the fact that users, on a computer, in a browser, really aren't looking to spend 2 hours watching someone's content.
This is important when building any app -- not just one that's video-centric. You have your user for a limited amount of time per go. Are you building it as such?
Super
Okay, so I've definately been slacking in the blog department for about the past, oh, 6 months. So, that being said, I'm going to make a concerted effort to post on a regular basis.
This blog is specfically around daily lessons and business logic that I learn being in the midst of a 2nd Gen web startup. (Is that politically correct enough of a term for everyone?)
Hopefully I don't reveal anything that'll get me fired, because I rather like my job. :)
Subscribe (RSS)