We Are From Mars
All agile methodologies stress the need of co-locating development with the customer’s representative – the Product Owner – or at least, having them in close proximity – both in time and in space.
Our team seems to be the exact opposite of what “the agile way” requires – we are located on the other side of the planet (Gdansk, Poland) from the company headquarters (Sydney, Australia). This means we could just as well be located on Mars. Actually, one could argue that outside of the narrow communication windows (early morning and late at night), communication latency between Sydney and Mars is smaller than the one between us and our Product Owner. Yet – we still manage to work in an agile way.
Talking To Each Other
How do we do it? First of all, we utilise high-bandwidth communication opportunities as much as possible. We have a local Product Owner proxy (that would be me), who talks to the Product Owner regularly, at predefined times and at least once a week. Also, if the out-of-band need arises, ad-hoc meetings are scheduled. Skype (or some equivalent technology) is your friend here, as well as Instant Messaging systems, such as Jabber. I cannot stress this enough – talking to each other in real-time is the most important and most effective way to communicate. I do not think it would be possible for us to work without it.
But that is not all. For us, the second most important communication method (and tool) is Jira – and it does the job just fine in its plain, out-of-the-box form. We use pretty much a stock Jira setup, with just two custom fields added (both reflecting standard Scrum practices) – one called “backlog order”, used for prioritizing user stories (a fancy word for “new feature or improvement”), the other called “story points” – for estimating the “size” of the user story. That suffices all our needs for making sure both the PO and us know what has to be done and how much delivering the requested feature is going to cost (after all, the effort estimates translates almost linearly into monetary costs). We also use the GreenHopper Jira plugin to provide “virtual story cards”, instead of maintaining our user stories on pieces of paper, to make our life easier when it comes to copying the outcomes of our planning sessions to Jira. But for day-to-day ticket management, we just use Jira. Or more properly: one of us (that would be me again) is using Jira, everybody else is just moving around the actual paper story cards on the cork board, which is a central part of our workspace.
What about the communication in the other direction? What if a Product Owner needs to describe some story to us, and words are not enough? Sometimes the Product Owner will want to draw a mockup of the user interface he has in mind. Here is where the Balsamiq Mockups tool is very helpful. It is a Confluence plugin, which lets you draw diagrams right there in the Confluence page, and share it with whoever you want to communicate with. We would typically edit the diagrams in-place and simply comment on them until everybody is satisfied with the resulting sketch of the user interface to be delivered.
How does the Product Owner know we are doing what he wanted us to do?
First of all, just as the Scrum methodology requires, we have a proper (internal) release every two weeks. The official builds are published in an externally accessible place for everybody to download and try it out – this gives us a way to regularly demo our progress and provides a way for the Product Owner to correct our course (e.g. whenever we stray from what has been planned or whenever the plan needs to be changed due to external circumstances).
Second – our Bamboo-based automated build system lets the Product Owner download and use the snapshot of our work every day – the snapshot may be barely usable, but typically it is in a good enough shape to let the Product Owner try new features as they are delivered.
We regularly practice dogfooding, using our product regularly on a daily basis. Almost every nightly snapshot is taken and used by each team member every morning. So if we happen to have a bug, we are quite likely to intercept it before the official version of the product is released. Also, if some user interface elements are awkward to use, or somebody has a bright idea for improving it, we are able to try multiple solutions and pick the best one – simply because we use our own software for our day-to-day work.
But in order to get even better feedback, developers in the Sydney office should also dogfood our software and give us feedback. Achieving sufficient levels of internal adoption requires a bit of advertising from the Product Owner, and regular presentations of cool new features that the product provides, so that folks in Sydney have a reason to bother installing our stuff.
Separation Of Responsibilities
The last thing that is important for a remote team and the Product Owner working with it is a separation of responsibilities. In our case, the Product Owner is only responsible for prioritizing features and controlling if they are delivered as promised. Planning and implementation are left to us. Also – all bug reports are handled locally by the team, as a part of the Quality Assurance process – we are solely responsible for keeping the product in good shape and the Product Owner does not interfere with that.
Another important rule we follow, is that the team’s effort estimations are final. The Product Owner (or anybody else) does not even attempt to question them, trusting our judgement – in true agile spirit.