Andy's Mind

I’ve been into web applications for some time now. First I used them, then I proposed them as solutions in some consulting projects then I got involved as development team manager in creating one (a billing/CRM system). But only now it occurred to me that ubiquitous Internet access and popularity of web applications are interlocked in a self-powering cycle.

As Internet access is more and more popular people start to use web applications more. As they use them they are more dependent on Internet access and thus demand it everywhere. One could extrapolate that once Internet access is available always and everywhere web applications will also dominate. And, conversely, if people indeed use web apps more they would need Internet access always and everywhere to keep using them.

It is interesting to see how the idea of Internet expressed in its name – the net to connect all nets – persists despite some trying to change it. This has profound implications for businesses trying to operate in this virtual world. Two clean and clear strategies can be seen – one is of an access provider and the other is one of an application/content provider. Those two species in the Internet ecosystem are dependent on each other, but they are distinctly different.

For an application/content provider the best idea is to reach as wide an audience as possible – potentially all Internet users (limited only by the languages they use) – with a clearly defined, appealing application set or content offering. Traffic means all to such businesses – no matter if they live off advertising or paid subscription. The more eyeballs you get to your web page the more money you make, period. Hence, limiting access or availability to a particular ISP or network is a bad idea, because no operator can match the number of potential users the Internet gives.

Conversely, for an ISP an opposite strategy is better. Such a business should focus on destination agnostic access. ISPs sell an easily-comparable commodity of access to all the Internet has to offer with only three simple dimensions of quality: price, reliability and speed. For them keeping a customer as long as possible and getting as many of them as possible per real meagbit of bandwidth is crucial. And to do that one has to stick to the basics – no amount of gimmicks, applications or exclusive content will ever help if the access is slow, pricey and breaks up all the time. It is so because no operator can match the amount and quality of applications and content available on the wide open Internet.

That’s why it is so rare these days to see people using e-mail addresses provided by their broadband operators. And why almost everyone uses some kind of webmail.

I was talking with someone about Scrum and other methodologies the other day and he said something like this: “all methodologies are like cookbooks, you don’t use all the recipies – in fact implementing them to the letter is not good, you should skip some parts“. It then dawned on me – and I quickly pointed it out – that Scrum is so simple there is hardly anything to skip.

If you look at the hard, “methodology-ish” bits then Scrum is just three roles (Team, Product Owner, Scrum Master), three meetings (Sprint Planning, Daily Scrum, Sprint Review) and three lists to maintain (Product Backlog, Sprint Backlog – with tasks and burndown chart – and Impediments). Not much to throw out – and nothing that would make any sense to.

I can, however, very much understand that people with experience in traditional project management approach are wary of implementing a methodology in full. PMBOK has a few hundred pages, RUP is so complex just understanding it takes ages and Prince-2 smells of centuries-old british bureacracy it was created for. All call for complex documentation and processes, all assume static models and formalized communication.

Indeed, the burden they call for can almost kill all the productivity in an organization. No wonder people learned the hard way that it is better not to follow everything those heavy books prescribed.

It is not easy to spot the moment when an organization looses its focus. But it is surprisingly obvious once it dawns on you. It can be likened to a knife loosing its sharpness. It is hard to spot the exact moment, but it is obvious once it stops to cut as it once did.

But putting allegories aside – in a startup I think it is the moment when it is not obvious anymore to everyone what their collective purpose it. It is the moment when business looses touch with reality and forgets about the basic product or service it provides turning its attention in a disproportional way to add-ons. It is the moment when the internal communication fails and the management team ceases to be just that – a team.

As I wrote already: communication is a crucial element here. In a startup it is, I think, always good at the beginning, when it is a small group of founders and first hires. Once a company develops past certain size – and especially if it becomes spread geographically – a dedicated, careful effort is necessary to prevent it from deteriorating.

Lack of this effort can be dangerous.

We’re well into our first iteration of the development project with all Scrum methods in place. We have a proper sprint backlog now, with tasks, kept in ScrumWorks. There are daily status meetings called Daily Scrums. I have to say that I do see the benefits already. Even though the team is a bit too small and I’m not always on site – so I’m trying to moderate over Skype, which doesn’t work as well.

The biggest benefit is, I think, a noticeable improvement in communication. Now I really do know every day where the team is, what was accomplished, what wasn’t, what’s in their way – and what chances we have to deliver on our promises. I don’t need any reports now. Even between the Daily Scrums I can always open the ScrumWorks and see what has changed. I hope the team feels the same way about it.

This improvement led me to see even more how much the whole management team could also benefit from better communication. A weekly scrum meeting could do wonders for a bunch of people, who spend most of their time traveling around the region, doing various things and not talking to each other.

Good, frequent communication in a team is necessary. Even more so in a dispersed one. But unless all those involved are from similar backgrounds, age groups etc. – and on top of that like each other – such a communication won’t appear on its own. It has to be cleverly fostered within a team. Scrum gives an excellent, simple tool to do so – the Daily Scrum meeting.