Friday, 9 October 2015

Popup Micro Communities, aka The death of Facebook by a thousand cuts.

I’m involved in seven at the moment.  Four of them are entirely work related, one of them is related to a political group I’m involved with and two of them are just for fun.  But what the hell am I talking about?

Over the last 15 years the way people do software development has evolved.  Moving away from archaic waterfall based software development methodologies, Agile extolls the importance of a face to face chat over a heavy dependence on documentation.  Of course, the internet also means that your software development team may distributed anywhere in the world, so how do you communicate and collaborate effectively with remote colleagues?

One of the earliest examples of online collaboration was through wiki software.  A shared, open space on the internet where users (with the right permissions) are allowed to freely edit content on web pages without requiring any HTML skills or having to upload files to a server.  These days wiki is highly refined with the likes of Atlassian’s Confluence allowing extremely fine-grained control over content access and real-time notifications when content is updated.  However, managing a wiki can soon become a full time job, its adhoc nature quite often resulting in a chaotic mess of information and is, of course, still no replacement for a face to face chat.

But people have been talking on the internet since its beginning with one of the most popular chat mediums in the early days being IRC, Internet Relay Chat.  IRC is built on the concept of chat channels, which these days people might prefer to think of as “chat rooms".  When you join an IRC server you would join one or more channels, most chat servers allowing users to freely create their own channels.  Once you had created your own channel you could control who had access to it, change it’s topic and various other settings.  Its protocol is surprisingly simple, based on the exchange of plain text, much like mail exchange protocols like POP3 or IMAP, that anyone with the patience and knowledge could engage with using a simple telnet connection.  However, the common user would normally connect to IRC with one of a myriad of applications, the most popular probably being mIRC.

Some of the greatest collaboration around software development has already occurred on IRC, but it’s not a great medium for sharing content and documentation in a way that people can refer to at a later date, the content of chats being fairly transient and file exchanges occurring in a peer to peer fashion.  Collaboration efforts over IRC would usually be combined with some kind of wiki.  IRC and wikis were inherently public and insecure, so creating community around these technologies would usually involve a company hosting their own wiki and IRC software which would require hardware and people resources to maintain.

It’s pretty clear the folks at Atlassian had a clear vision about how online collaboration could and should work. JIRA has to be the world’s most well know “ticket management” system, allowing people to create tickets (known as issues) in order to track user requirements, user stories, tasks and defects and more.  The Atlassian stack is well integrated so once configured you can have updates to JIRA appear on Confluence pages or even in the chat rooms on Atlassian’s own version of IRC known as HipChat.   HipChat is like IRC but accessible using Atlassian’s own software or via their website.  It also adds file sharing and allows users to share files in the context of a conversation easily while being able to see the historical transcripts of conversations that have happened.

These days it’s really easy for anyone to spin up an instance of an Atlassian stack giving them a wiki, real time chat, and ticket management but there are alternatives out there.  Rather than adopting a whole stack groups may only need a small portion of the stack initially so may decide to sign up for just a HipChat or Slack. 

Slack is an alternative to HipChat and, sorry Atlassian, I feel it has a superior user experience.  In some ways it is even more like IRC that HipChat, but with a user interface that is unobtrusive and a pleasure to use and like HipChat allows contextual file sharing.  

Whether you choose HipChat or Slack, or something else, once a team decides they need to add something else to the stack, it’s relatively easy for them to go out to the web and sign up for a wiki, or a task board, or issue management and then integrate it with whatever chat system they’ve decided to use. 

However, software development isn’t the only reason to use a HipChat or Slack. 

Even though Slack is relatively new, both companies have a strong reputation for reliability and respecting privacy, where as users of Facebook are becoming increasingly concerned with Facebook’s ever changing privacy policy and the fact that content shared there is only lightly secured.  For instance, post a picture to Facebook in to a private group, then right click on that picture, copy the link, and open that link in a browser you’re not signed in to (or send it to a friend not in the group) and you might be surprised to find that you can still access the picture.  Also consider that Facebook reorders content using secret internal algorithms which judge how relevant your content is, and that it is constant analysing content and the users who interact with it in order to sell that data for marketing and advertising purposes.  Facebook groups feel like a natural place to create a community, but the nature of Facebook’s post and comment approach means that Facebook groups become little more than soap boxes where only the loudest get heard.  True collaboration on the Facebook platform is not possible and the chance of private data leakage is high.  And I haven’t even talked about advertising.

So when groups of people - (ex)colleagues, friends, families, political groups, etc - want a place to collaborate, chat in real time, share files, and so on, tools like HipChat and Slack are a perfect replacement for the Facebook group. They are generally free to use and your content is safe and secure, because the reputation of the companies hosting these tools depends on that.

Thus the Popup Micro Community is born and the death of Facebook by a thousand cuts begins in earnest.

Monday, 23 February 2015

One week sprints could work for you - but probably won't.

I've been working using the Scrum methodology of agile, or some derivative of it, for many years now.  Over that period years I've worked at several different places who have all had a particular sprint length already established when I joined the team.

The one I enjoyed the most was the one-week sprint.  When you say this to people they usually balk, but the context for the one week sprint was just right.  Our product was single platform and we only interacted with people outside of the engineering team once a week in order to demo and plan for the following week.   The same day we would have our team retrospective and because it was Friday we'd either go to the pub or go home early.  Four solid days of development and one day off for admin type stuff, it worked really well and we were incredibly productive.

But the one week sprint can only work well if you have the right conditions:

  • The team can work in relative isolation with the scrum master as a conduit, getting answers to questions quickly.
  • The team feel empowered to make executive decisions.
  • Your team is single platform with little or no external dependencies.
  • Sprint starts on the Monday and finishes on the Friday.  
For me the one week sprint falls over pretty quickly when:
  • Your team is multi-platform.  For instance, developing mobile and server functionality concurrently.  The additional collaboration required means none of the devs can knuckle down and get work done.
  • Inter-team dependencies.  The more people you know, the more likely you are to get random interruptions, which break train of thought.
  • Your team is not co-located. If you have anyone that contributes to the sprint in different locations, then your ability to collaborate is severely hampered.  You'll use Skype, email, conference calls or some other tool and will then likely be asked why you're having so many meetings and using email to communicate.
  • Your scrum master is unable to to shield the team from distractions (for whatever reason).
  • You can't end your sprints on a Friday.  Stopping and starting during the middle of the week is counter productive for a couple of reasons.  Firstly, the Monday and Friday are natural delimiters for working.  If you have unfinished work on a Friday, devs will naturally ponder it, or at least feel a foreboding about it, over the weekend.  As a result they are not winding down and will burn out.  Secondly, having has the weekend to completely switch context Monday will naturally end up being a day of getting back up to speed.  Anecdotally, devs are most productive on Tuesdays and Wednesdays, maybe Thursdays.
  • Any of the above combined with an open plan office.  Open plan office is basically a forum for open discussion, people shouting across desks, people wandering around making noise and generally being distracting.  Give your devs a quiet area to work.  Joel Spolksy highlighted this about 15 years ago.  If you wonder why you see your devs working with headphones on "when they should be collaborating" this is why.

So I've been trying to work out how to determine the best sprint length, but there really isn't a formula.  That said, it is easy for me to say that unless your conditions are perfect, as described above, one week sprints aren't going to work for you. Personally, I would like 4 days of solid, relatively uninterrupted time to make quality progress. In this case, start with two week sprints.  This gives your devs time to work, but also builds in contingency for collaboration. Use retrospectives to let the team express their desire for shorter or longer sprints and listen to them.  Work around your engineers rather than forcing them to work around other parts of the team that are not actually producing something.