As our business continues to expand, we have been facing some interesting new challenges and opportunities. One that has been on my mind a lot lately is cross-site collaboration. But no good solutions exist that enable us to feel a little bit more like we are in the same room. I am tired of seeing startups attack geeky problems that no one cares about. Virtual team communication tools pose a problem for a lot of folks, and I know that many of us are willing to spend good money on a solution.
Cross-site collaboration is hard. Lots of things about that really bother me. First, it’s 2010. This shouldn’t be a problem in this day and age, but it is. And I am no stranger to virtual teaming — I have been doing it for nearly 10 years (before it was cool). What I have found over the years is that many of the very typical challenges with virtual teaming are actually surmountable. Things like timezone, language barriers, and even cultural differences can be managed.
But the thing that no one seems to have a great handle on is collaboration. Most people will tell you that they have no problem collaborating in their virtual teams — but they are wrong. They aren’t collaborating in the way I am talking about. Anyone can sit in a chat room, use a wiki, and contribute to a Google doc. But those of us who have done as much ‘real life teaming’ as we have done virtual teaming will tell you that it’s just not the same.
And here’s why: the secret to great collaboration and teamwork lies in the unplanned interactions.
The amazing thing about being in the same room as some group of people is that you can just walk over to someone whenever you are struck with an idea. And you have a clear sense of ‘presence.’ When you need someone, you can just look over to their workspace and quickly see if they are engaged with someone else, not at their desk, or on the phone. Wikis, chatrooms, and the other standard virtual fare don’t get you even close to that sort of connection. You lose the power of that ‘instant-on’ communication.
Ok, fine, so it’s frustrating and hard to collaborate virtually.. particularly when you are spoiled by great ‘same room’ interactions. But that’s not what kills me. What kills me is that there is a real business need, and the market is wildly underserved. All the while, I feel surrounded by a number of geeked-out companies that are solving technical problems that don’t appear to be worth money to me.
As a funny aside, it turns out that I am not the only one who notices the ‘overgeekiness’ of startups here in the bay area. While I love being a geek, I have come to learn that solving geeky problems is not always the best way to build a real business. Anyway, a well known and well respected VC recently called these businesses “boys building bigger toys for other boys.” Haha, I love it.
Ok, back to the point. This collaboration and cross-site communication thing is a mildly geeky problem for which I’d actually pay money for a solution. And no one has done anything about it! Ahh! Maybe the problem hasn’t been framed well enough. So let me quickly build the case for why someone should really take a stab at solving the collaboration problem:
So, in some ways, the stars are aligning for a good collaboration tool for virtual teams. Ugh, I don’t really like the term ‘collaboration.’ It sort of lumps this into the same category of SAAS web apps like Basecamp and ProofHQ. That’s a whole different kind of collaboration and team management. But that’s not the kind presence, instant-on, better communication tool I am talking about here.
The tool I am thinking about, of course, centers on video as the medium. It’s something that helps groups and teams in different places feel as close to being in the same room as possible without actually being in the same room. That’s what we need. (And we can’t be the only ones who need it!)
Here are some thoughts on what would make a decent product:
So that’s it. That’s the end of my rant. I hope that VCs and entrepreneurs alike wise up to the opportunity here. The need to collaborate is not going away anytime soon. We are in the year 2010.. and I still feel like we’re in 2000.
I have to believe someone out there can be crafty and combine commodity hardware with open-standard software to create a really exciting and affordable solution. Whoever does is going to get a lot of orders from me!
In my last post, we just began exploring the idea of agile design. The quick conclusion was that there are significant similiarties between design and development as creative processes. Agile thinking can be effectively applied to both. The big question is about specific implementation. How would it work?
There are two ways that I have seen agility applied to design. For lack of better terminilogy, I’ll call them the:
Let’s start with a quick explanation of what each wheel means. The two-wheel approach treats design and engineering as two separate teams (or even two separate organizations). In the two wheel approach, the both teams are working iteratively to push ‘shippable deliverables.’ For designers, it would be shippable designs. And for coders, it would be shippable code.
The natural progression of work tends to be that the design is done before the development. As such, the the design iterations generally drive the development iterations. Once a design product has been marked as solid enough for implementation, it is ‘completed’ in the agile design cycle and it marks the beginning of an agile development cycle. The lengths of the iterations don’t have to be the same across design and development. In fact, I’ve seen shorter design iteration length have a better chance of success.
The one-wheel approach is primarily different in that it treats design and development as one ‘product development team.’ This is a cross-functional agile approach for which there is very little precedent. In this approach, the team is all pushing towards one shippable deliverable together, and each person is doing their part side-by-side with folks of other disciplines.
In the one-wheel approach, the work is not as cleanly sequential. What ends up happening is that some work is sequential, other work is parallel, and a lot of work ends up happening in mini-iterations within the iteration. For example, a designer may produce a mock and pass it to a developer, but can be involved in ensuring that it is implemented in a pixel perfect way by the developer on the team. As the developer has real-time feedback, the designer could very quickly re-mock and pass the mock over again. As the UI of the app increases in fidelity, the designer can start producing unforeseen assets like icons and other images that are implemented downstream.
Of course, the million-dollar question is: which approach is better? The honest truth is that I don’t know yet. I have used both and have seen pros and cons to each.
The advantages of the two-wheel approach are:
The advantages of the one-wheel approach are:
What I am trying to figure out now is: are these approaches more or less appropriate for different circumstances or phases of growth? I, unfortunately, don’t know the answer yet. Of course, if you are not in a startup or not in a position to mold the structure of your organization, then the constraint of organizational structure can drive your decision. (Most of the time, that will drive you to the two -wheel approach.)
The one-wheel approach has some potentially large benefits (like better product outcomes and more buy-in!), but it takes a lot more organizational buy-in. Cross-functional teaming can be very complex to implement, particularly in organizations where different leaders of different organizations have strong visions for ‘how things should be done’ in their world.
I’ll try to report back after I know more!
So, I have been fortunate enough to be part of a lot of conversations with a lot of smart people recently. A good number of them have been centered around one topic: agile design. For me, it’s sort of funny that this topic has come more and more into the spotlight over the last year. The first time I started talking about ‘Agile Design’ was in 2008, when ModCloth was just starting to build out it’s design and development competencies. Back then, I think people mostly thought I was crazy. The feedback was plain and simple: “agile doesn’t make any sense in design. Developers don’t understand our world. Our process has to be ‘creative.’”
Today, I think folks are slowly but surely coming around. If I had to guess why, I would say that it has to do with the environmental factors mostly. Agile methodologies have grown in popularity, considerably so in the world of software development. A lot of folks have been evangelizing their specific brand of agile over the years, and I feel like it’s really hitting a tipping point. (Or more likely, it has already hit the tipping point.) So people are realizing that agile is really here to stay, and that means that it’s really hard to ignore in the design world. The most compelling reason, of course, is that one of the core principles of agility is empowering the team. So if the software developers are empowered to start envisioning the software — when do the designers get involved? Well, in some companies I know, the designers are mostly charged with making stuff ‘look pretty.’ How fulfilling is that?
Ok, so agile is here to stay. And it creates a weird situation for designers (and others) in organizations where only the software developers are practicing agile methodologies. And now days, people are starting to throw around this phrase ‘agile design,’ even though what it means is is not clear to anyone. So, let’s figure it out:
The core principles of agility are simple, in my words:
Because I can’t live with myself without sketching out a quick visual of how these principals drive one another:
So, before we do anything else, let’s ask ourselves this: do the principles above apply to design? My gut tells me the answer is yes. Chaos is a reality of nearly any organization. You cannot clearly predict the future, so you have to be ready for change, and you have to be ready for your vision to evolve. And the same bravery that would enable a developer to show someone their code or their half-complete feature is the very same bravery needed by a designer to show someone a design before they think it’s 100% ready, no? And the principles of iterative work and collaboration also still apply to design, no?
So can you engage in agile design? The answer appears to be yes. Is it exactly the same as agile software development? Of course not. It’s safe to say that both software development and design are creative processes. But they are not exactly the same in terms of how they are accomplished (or how long they take to get accomplished.)
But there is more to this topic than meets the eye. If your organization is going to buy-into the idea of agile in the realms of both design and development, how are you going to enable both of them to get together? That seems to be the core question. I’ll followup with some thoughts on that soon!