Official Blog

Process & control: Do a Jira

In the contemporary world Michael Foucault, a French philosopher, thinks that organizations are places of controlled violence. Another tradition embodied by the American philosopher John Dewey, views organizations as edifying forums.

Whatever we think of organizations, either as incubators of new cultures, or as defined by the cultural milieu of our societies at large, most, including the cited philosophers, think they are artificial and therefore open to to being remade.

One area how we on purpose remade our organizational setup was the development process and issue tracking. Scrum, our preferred project methodology splits our entire project into stories and tasks assigned to two-week sprints.

Years ago we would handle project tasks with huge Excel sheets. Not a very amusing job, especially if you had to track a larger team. The burden was even greater on the team having to track their tasks.

During these celebratory days of 40 years Moon landing, I always wonder how the folks did it at the time without Wikis and without digital task tracking. 40 years later the problem is solved – digital distributed task tracking does the job. At Nektoon we use Jira.

Jira is a sister product of the Confluence, our Wiki software written by Atlassian. We simply got used to their product after our happy contact with their Wiki software. And additional benefit is, that both are tightly integrated.

Every issue, task, bug, improvement is recorded in our Jira. On a two week basis we assign these issues to individual members of the team. Once you start to work on an issue you register your work: We comment on the progress of our work and clock the time spent on each task.

With this we accumulate a body of data that allows us:

  • To increase the quality of planning, scoping of our issues and projects, and
  • To improve the actual implementation.

Furthermore the system allows: 

  • Each team member to see at each moment what open tasks there are, and
  • To whom they are assigned to
  • What the progress on each issue is
  • How efficiently and effectively we move forward.
  • In case we run off course by too much, to see this early on and decide what measures to take.

For us the relevant part is the transparency of our issue tracking. We are able to manage hundreds of issues, assign accountability and ensure that things get done.

Next in the series how to build a scalable startupShared nothing architecture.

 Permalink

Abolish (MS) Office: Wiki will do

Most theories of editing are based on the idea of a single author. Stillinger, an American professor of English literature, calls this the Myth of the solitary genius, and points out that most “works can and frequently do have multiple authors, sometimes with divided and even conflicting intentions among them”.

Friedell, an Austrian historian, is more candid and reckons the discussion about plagiarism to be the most unnecessary controversy in history. Nature does not allow dishonest business, he writes, and goes on to unveil that Alexander borrowed from Philip, Augustine borrowed from Paul, Schiller borrowed from Shakespeare, the latter was influenced by Plutarch. Friedell concludes that dark times like the Middle Ages are always the result of insufficient intellectual larceny. He would have loved the Internet. Goethe, a German poet, rightly questions the sense of asking a well-fed man about all the ox, sheep and pigs he ate to give him strength.

Back in 2005 when we started with local.ch, we had to conceive and build the platform within just six months between October 2005 and March 2006. We were a team of nearly 40 people from six different companies. First, we split the platform into different building blocks (see previous post). Each sub-team had an organizational and conceptual challenge to document and a requirement to update and get updated by all the other sub-teams.

Most of you know what now happens next: An avalanche of E-Mail with zillions of attached specification documents, presentations, Excel sheets and more. After just a few weeks, nobody would ever know again which was the latest presentation, which was the agreed specification, which was the most up-to-date business plan Excel, etc. A nightmare!

What matters at launch – and this differs sharply to Roger Federer’s single achievements – is a team effort focused on a well-executed solution. It is not important who wrote what, but what we wrote. A solid specification is a collaborative effort. Thus we were looking for a highly collaborative platform for specification and documentation: A Wiki.

Wikipedia is well known to all. Within no time it surpassed the venerable Encyclopedia Britannica. Collaborative editing proofed a wining concept. A little less known is that the same technique may be applied to company internal collaboration, too. At least back in 2005 it was a novel concept.

A Wiki enables documents to be written collaboratively using a Web browser. Its main advantages are:

  • Collaborative authoring: Anyone can access any page and edit any page
  • Everybody sees what’s happening
  • Each page has a stable URL
  • Automatic versioning for documents
  • Search across the entire Wiki

Basically it’s massively distributable collaboration: People located at different places can work on the same document.  

I don’t want to hide a number of disadvantages I came across spanning four years of excessive Wiki usage:  

  • It requires Internet connectivity to collaborate. Offline is off work. Happened to us when our service provider once put us offline for two (sic!) days.
  • The flexibility of a Wiki's structure can mean that information becomes disorganized. A Wiki needs constant care.

The adaption curve was not a linear road. For quite some users to work with a Wiki was a laborious task at first. You edit online and all colleagues immediately see what you do was an odd notion. Plus we realized that the MediaWiki [ http://en.wikipedia.org/wiki/MediaWiki ] syntax proved quite difficult for some users: Some clever clogs simply attached word documents to Wiki pages.

Over Christmas 2005 Toni and myself evaluated a number of alternatives. We wanted a Wiki with a rich text editor for people to avoid the Wiki markup. We choose Confluence from at the time little known Australian startup called Atlassian. A choice we stuck to ever since. As a matter of fact, a couple of friends from liipnamics, Zeix, Blogwerk, PubliGroupe et al. came to learn from us and subsequently introduced and enhanced Wikis in their companies (in case you want a live demo contact any of us).

No surprise then that pretty much the first thing we set up when starting to think about our new company back in 2007 was a Wiki. We could asynchronously work over weekends and late at night and yet still see at the very same time what the others were doing.

Today we collaboratively work in our Wiki on specifications, technical documentation, business issues, project management, bookkeeping, people affairs and we open up our Wiki for our cooperation partners. What counts is not the single genius but the joint effort.

Goethe would have approved.

Next in the series how to build a scalable startup: Process & control.

_______

Stillinger J., “Multiple Authorship and the Myth of Solitary Genius”, Oxford: Oxford University Press, 1991.

Friedell E., "Die Kulturgeschichte der Neuzeit", originally published in 3 volumes, Vienna, 1927-1931, München: Beck, 1996.

Comments (2)  Permalink
1-2/2

Categories

LiveSearch

Archive

Team blogs

Twitter

Twitter Updates

Feeds

Pressclippings

Memonic Set by press

RSS Feed

memonic Photos

More memonic photos