The Blog - Archive for

Notifications in SWM [product update]

by Chris M. Filed under: Products

We’re excited to introduce a new feature in SWM: notifications are a new way for you to keep up-to-date with the latest news from the SWM ecosystem. Notifications are now enabled across all accounts in SWM. This means that over the coming weeks you will begin to see notifications appearing throughout the system in various guises.

We have designed the notification system to be flexible and adaptable for future needs, but initially we will be using them to make announcements about new features to SWM users, from within the SWM interface, and to provide extra help and information to new users of SWM.

When you visit a page with a notification attached, you will see a box at the top of the page with the content of the note, once you have read and absorbed the information, you can close the notification using the small cross in the upper right corner, when a notification has been dismissed it will not be displayed again. There is one exception to this rule, when we decide that a notification needs to be sticky, you can’t dismiss sticky notifications. But don’t worry, we’ll only be using these on rare occasions where we deem it necessary, if you forget to pay your bill for example!

This feature is still in its infancy, and I’m sure we’ll find more exciting uses for it in the future. We’re always keen to hear feedback from our users, so if there’s anything you think we could improve or change to enhance this (or any other) feature, then please get in touch with us and let us know.

11 things we do for effective bug tracking

by Mark P. Filed under: Knowledge

Dealing with bugs can be a very dangerous experience… For a small company it’s possible to drown in the bloody things. Effectively getting a process in place can be difficult and time consuming. We currently have a few big projects on, so we know this first hand.

The Basics

A few “givens” are necessary before any kind of bug process can be implemented.

We need to have:

  • A “deployment” server (the live one)
  • A “stage” server
  • A system for tracking bugs

While developing a sprint there should be a “development” server – bugs are never reported on a development server as it’s always “bleeding edge” work in progress. This development can still be discussed in whatever project management software you may be using.

We use Mantis for tracking bugs, it’s not got the best interface around but it’s depth suits us well at the moment.

Our process isn’t some multi page document it’s just a simple list of rules that will make the client’s and our lives easier during the bug tracking phase.

All bugs and features must go into bug track

One mans bug is another mans butterfly… Put everything into the bug tracking system, ambiguous or not. Leaving things out just causes confusion later.

Any communication around a bug or feature must be in bug track

There’s no point getting a zillion emails about an already reported bug. As a project manager if you have to put it in; do it. Any correspondence can then be centralised around that bug.

All communication with developers must be through bug track

When a developer gets emails directly it messes with their minds. Nine out of ten developers rise to the challenge of the client, which is great, but the project manager needs to be involved, hence keeping everything in bug track.

When a bug has been received it will be assigned to a developer

In your bug tracking software you should be able to assign bugs to developers. This shows the client that you’ve acknowledged the problem. Once a problem is acknowledged and a line of communication is open a certain amount of stress is relieved on both sides.

If the bug is deemed to be a “feature” it will be assigned to the project manager for discussion

Developers are lovely. They will fit in this small feature even though it’s not really a bug. Anything ambiguous needs to be assigned to the project manager.

When we have looked at the bug we may have some questions

The developer will change the status to “feedback” – asking for what we need to know. The quicker it’s answered the sooner the bug will be resolved.

When we’ve fixed the bug we will push it to the “stage” server for approval

The staging area is the latest stable release before the deployment to the production server.

If the client is not satisfied that the bug is fixed – why?

We need clear information stating why and under what circumstances. This needs to be attached as a note against the bug in bug track.

When the client is happy that the bug is fixed – close it

A note in bug track needs to be attached to the bug. Only then will we “close” the bug.

We will not deploy to the live server individual bug fixes unless they are catastrophic

Deploying individual bug fixes is inefficient, so unless they are really really bad, they will be stored up into a daily or weekly release.

We will provide a list of fixed bugs deployed to the live server

It’s important to know what has been promoted from the staging server. A clear list of bugs and their issue numbers should be provided to the client either by email or in your project management software.

This is a work in progress, an evolutionary process if you like. It would be fantastic to compare this with other agencies so that we can collectively improve the way that we treat clients and out own efficiency.

Defining our terminology

by Mark P. Filed under: Company

We use as little terminology as possible day to day. Even so we still tend to take it for granted that everyone should know what we mean.

It seems like a good idea to put these online so that we always have a point of reference; like a mini Wiki.

Definitions

Project

A complete development from start to finish made up of sprints.

Sprint

A part of project that delivers a specific business requirement. Each sprint is made up of iterations.

Iteration

A part or revision of a sprint that provides specific functionality.

This post is a work in progress and will be added to as infrequently as possible…

Introduction to Media Genius

by Mark P. Filed under: Products

This is our first screencast giving an introduction to Media Genius. It’s an overview of installing an application and setting up a workspace.

Click the full screen icon for better resolution.

Psycho Analysed by Video [fun and games]

by Tom H. Filed under: Company

We now have some very talented developers including Ferenc, Luke, Ben, Christos and our newest team member Chris and we’re about to take on a marketing manager and an office manager.

It’s exciting times and it seems every month brings a new face to the office.

In an effort to make people quickly feel like part of the team, and to help us all learn a little more about each other, I like to run a monthly light-hearted competition.

The competition for February was simply “pick your favourite video related to our industry”. There were two prizes up for grabs, the first went to whoever submitted the video the team liked the most, the second went to whoever guessed the most amount of video submissions correctly “who submitted what?”. The latter task, I thought, would be an interesting insight in to their colleagues personalities and interests. It proved to be more difficult than i thought. Even though I was the only one that had seen the entries, I still managed to get some wrong!

Here are the videos:

Mark

Lewis

Ben

Me (Tom)

Ferenc

Christos

Luke

I think Les was a little upset I’d left him out of the competition, I promise, next time, Les will be taking part!

Chris wasn’t with us at the time so the March competition will be his first.

And the winners:

Well, Mark really won both tasks. That being said, his video wasn’t related to technology in the slightest (no suprise he ignored the rules!), so I awarded the best video to Luke and the guessing of the person that submitted the video to Mark. I’m pleased Luke won this month after taking the runners up santa hat the previous month!