During the demo’s at a recent startup weekend event in Edmonton I was fortunate enough to have the opportunity to share the experience of starting a technology company and eventually selling it. I also highlighted some lessons learned, things we did right, and things we failed at.
I plan on writing posts that dive a little deeper into the presentation, but for now, here’s the slide deck from the presentation.
software start up
The lighter side of Collabomatic
Today was the first day that Dwayne, Rod and I were all together in the same room after “becoming a real company.”
We’re not anywhere near claiming victory until millions are enjoying using Collabomatic, Dwayne is navigating his submarine across Lake Washington, I’m flying overhead in my new helicopter and Rod is catching up on 5 years of TV absence by watching his very own HD set … But …
Being able to focus, pay ourselves, and plan for the future does feel a bit like a milestone achievement.
So after getting home from dinner in Seattle tonight, I became nostalgic and started digging through my emails from some of our early conversations. In doing so I started to compile a list of some of the funnier and more notable moments from the last 10 months and did what any good nerd would do … I blogged about it.
In no particular chronological order, mainly cut and pasted from email tonight, as well as memorable quotes from various conversations that stand out ….
“Mom; please please please could you not use the phone; I’m waiting on an important call”
– Rod, about 30 seconds before receiving a call from potential investors while we were still working from his parents basement.
“I unplugged the phone upstairs just in case she tried to pick up during our investor call”
– Rod, still paranoid, the next day about 5 minutes before a follow up call with potential investors.
“My Elevator pitch requires about a 67 story building”
– Dwayne, when describing his elevator pitch at a recent startup event.
“David and I just finished our lunch. David’s a pretty good guy
— great hair, likes the right beer. I won’t screen his calls.”
– Rod, to Dwayne and I after Rod and I met for the first time on a “geek blind date” at Mongolie grill in Edmonton.
“We really need a codename! I can’t get through a pitch without someone in the room laughing every time I say “Collabomatic.”
– Dwayne, in an email to Rod and I after giving a pitch to some Seattle Tech startup guys. 10 months later, we still call ourselves and our product “Collabomatic.”
“Damnit”
– Rod after spilling coffee on one of his only 2 dress shirts that made the trip to meet potential investors in Texas.
“Get your mom and dad to move to Edmonton. Problem solved”
– Dwayne, in an email to me after I told him I wasn’t sure what the he@#ll I was going to do now for money now that I had quit my job.
I’m sure this is only the surface and I’ll wake up with a fresh new set …
QA Process in Plan driven environments
Background
It had only been two days since I left Saflink … a small-sized software company, working within an enthusiastic, agile project group in Seattle Washington … to a large, bureaucratic, development team working on a government contract in Edmonton Alberta – and the differences were already starting to wear on me.
Before I continue, I feel the need to state my intended purpose for writing this blog. While I do admit a certain amount of spite and malcontent (and I’m sure this will become obvious), I do not intend to speak ill of plan-driven environments and their effectiveness – I’d be foolish to think that these methodologies are not needed in certain scenarios such as large, governmental, highly formalized projects. However, I do believe there are many lessons to be learned and practices to be adopted from the agile startup world that could benefit these top heavy projects. Having a background … and what I like to refer to as a startup mind … I am constantly seeking ways to infiltrate the seemingly impenetrable wall of process definition, best practices, and documentation with injections of agile practices. The intended purpose of this original blog is to define these two environments. Further blog contributions will discuss ways in which I (and hopefully others) have effectively instilled agile methodologies within a process-driven environment.
The agile culture
Instead of going to great lengths describing the previous agile, startup environment I worked in, I will attempt to summarize briefly. Our small project team was proud, passionate, and had ownership and belief in the product that we were building. We were small, adaptable and not bound by procedures and best practices. Each team member was not defined by their role (as a matter of fact, we avoided using words like project managers, developers, testers) however we were expected and trusted to do whatever work was necessary to succeed. This included seeking common or unnoticed tasks and completing them. Side effects of such a culture were long hours, hard work, innovation, new technologies, team lunches, playstation sessions, over the shoulder code reviews and troubleshooting, ad-hoc collaboration, outside the box thinking, and a lot of progress towards our end goal.
The plan-driven culture
In contrast, the environment which I have been immersed in recently is a plan-driven culture. People feel comfortable and empowered only when there are clear policies and procedures (and a document) defining their roles. Their work is done when their current task can be ticked off on a spreadsheet. As a matter of fact, you are discouraged from starting up a new task until given direct instructions (in the form of a new task in a gant chart). Developers (who insist on being referred to as “analysts”) are instructed (only by project managers) on exactly what to build and exactly how long they have to do it. I often reflect on a comment made by a project manager – “Our goal is to define the software to such a degree, that we can hand off the specification document and developers can simply *puke* out code”. While this would be about enough to cause any believer in agile practices to jump off the 10th floor, I have tried (unsuccessfully however) to believe that the nature of some projects (such as ours) require such definition and precision. After all, developers … er I mean analysts here … don’t seem to mind this mentality.
Boardrooms outnumber test labs 5 to … well … there are no test labs. This would disgust Vincent Maraia who wrote in “The Build Master” that the success of a software organization can be directly measured by the ratio of computer labs to board rooms.
Finally, the sense of ownership and pride is non-existent. On my first day, my question on how to acquire remote access to the domain was answered by a look of confusion. People simply don’t have an affiliation and a sense of ownership over what is being built.
Removing barriers and applying agile methodologies
Again, I am a strong believer in agile approaches and feel this is where I’m most effective. However, I believe there are some projects that call for more of a structured approach. The challenge is finding the balance between the two … I believe the lessons I have learned from the agile startup environment can be applied to this top heavy process. It is our challenge (as startup minds in slow-down cultures) to cut through the red tape, and fly under the radar in our attempts to speed up (while not undermining) the processes currently in place … and overall, maintain our sanity.
David Quail 