Kennis IT Quality – Less tools, more collaboration

IT Quality – Less tools, more collaboration

Ok, so we all understand that building great software requires a lot more than just a bunch of super skilled nerds producing superb code (see my previous post on the subject). It's all about teamwork - about dedicated people from all disciplines collaborating efficiently throughout the entire software project lifecycle.

But how is this best achieved when each discipline uses different tools?

Variety in tooling will put up walls where you don't want them. Can team members access the tools? From anywhere? How's the learning curve? How will a developer make a quick adjustment to a project's planning? Where will a tester go if he/she has a great idea about detailing a requirement?

Specifically, how are team members going to access, update, comment and/or use the information they need to do their work and to contribute efficiently to the overall quality of the project?

Of course, many specific tasks do require specialized tool, you can't get around that. But what about the information, the knowledge (the documentation) around the actual task/skill?

It used to be that every discipline/team member used different tools. Everyone did their own thing really and access to information was an 'on demand' kind of thing. Everyone would use email and text files to store some of their information, then a project manager would use a planning tool; a requirement engineer, a word processor; a software architect, a diagramming tool; a tester, a spreadsheet maybe and well, developers would use a bit of everything I guess...

Luckily those days are gone!

For us, it's really important that team members have access to all of the project's documentation without needing to install (and master) a whole series of tools. Our primary objective is that both performance and quality be off the scale. So while we do recognize the importance of people taking responsibility for specific steps in the cycle, we don't want to be too strict with given roles and responsibilities, because we feel we should all be equally responsible for the end result. So in order for that to happen, everyone needs access to pretty much everything.

And that's why we love Confluence so much. It made information accessible to everyone and it allowed us to get rid of a bunch of those personal tools. It quickly became a platform from which to extend our collaboration. It's low tech, easy to implement (no steep learning curve), multiplatform (an internet browser is all you need) and it has everything you need for real-world collaboration - out of the box (comments, share button, watching, mentions, version history, activity streams, status updates, dashboards, etc.).

Since we implemented it over 5 years ago, we've said goodbye to the word processor, the diagramming tool (thanks Gliffy!), the spreadsheets, the planning tool, the drawing tool, the wireframing tool (thanks Balsamiq!), the screenshot tool (thanks OSX cmd+shift+4!), etc...

At this point it's a reflex... everyone simply goes to the wiki/intranet to access, add or edit the information they need. There's no more information hidden away somewhere in an email or text file on somebody's computer... Even people that have to work with specific tools are required to document what they're doing by adding screenshots (for designers) or embedding code (for programers) and uploading the file when applicable. That way we all know what's really going on.

And, in our case, the client has access to pretty much all of this - and that took a lot of effort out of realizing our goal of being totally transparent!

Of course there are many alternatives out there, and your choice is as good as ours... it's about finding a collaboration platform that's right for you. That said, we chose Confluence and we're very glad we did!

Now each discipline can just focus on the true objective: Shipping superior quality projects in the most efficient way possible.