Subject Matter Experts

Sometimes on a project your team will include a Subject Matter Expert (SME). I think the general idea of these individuals is that they provide deep domain experience to members of the project team who may not really understand the space they’re working in very well – makes perfect sense. A couple of examples where I have seen the SME role used is implementing GIS within utilities and local government. In both contexts the SME provides an in depth knowledge of their respective domain, i.e. a water network, or perhaps a government property model. They may provide expert advice on entity modelling and relationships, provide real world data examples and scenarios and of course act as a natural liaison with other parts of an organisation you may need to dig into.

There are a few things however that concern me about how the SME role is often used:

1. Authority

The SME role can exercise a great deal of authority. Executive sponsorship will often cede responsibility to an SME irrespective of the nature of the calls they need to make. SME’s can also be viewed or boxed into the de-facto representative for ‘the business’. In a Scrum environment I would caution the use of an SME  as a replacement for the product owner role. Whilst they provide invaluable experience, they are not necessarily positioned or motivated to assess value or make calls on priorities.

2. They aren’t users

In my experience an SME role is often given to someone who has a great deal of experience. However that experience is associated with a perspective based upon a deep understanding of detail which may not translate well to the goals of the project. Take our utility example, an SME can provide information on the logical and physical networks, helping you model data and understand the relationship and behaviour of the real world network, however that depth of knowledge does not necessarily translate to the needs of a customer service representative or an incident response operator. SME’s aren’t always users.

3. Edge Cases

I have found that SME’s can have an intimate knowledge of edge cases, whilst these are not invalid you must decide where these cases sit within the overall value you’re trying to deliver  – I’ve worked on projects that have literally ground to a complete standstill while edge cases are reasoned  - with the end result being an over complication of the finished product yielding little real value.

If you’re working on a project with an SME then it can be useful to keep these questions in the back of your mind.

The missing ceremony

It’s been a while since I got my act together and posted here – this seems to coincide with the purchase of my android and a preference for posting expletives to twitter.

So I’m about to embark on my third scrum project and I  thought it a good opportunity to reflect on my personal experience on those first two projects. In particular I wanted to briefly rant about what I’ve been calling the missing ceremony of SCRUM.

On my first project I acted as the Scrummaster  - On this project we were just dipping our feet in the water and I enjoyed the experience (..and the project went well). In my second project I entered the project midway and was asked to take on the Product Owner role.  I entered the team during the third Sprint, and my predecessor was still involved so I was lucky enough to act as observer for the first couple of weeks before diving straight in. There was a bit of disturbance in the team in the overlap between Sprint 3 and 4 – I was coming in as Product Owner, our Scrummaster had scheduled leave and as usual I had a boat load of other stuff on the go…anyway we committed to Sprint 4 and away we went. I began to notice that during Sprint 4 the team were having quite a few interpretation issues regarding the stories which we’d committed to. Now I believe there are two ways of looking at this issue:

1. In an ideal situation we can take a story from the backlog and have on hand all the resources and people to discuss what the story is all about, this might be a BA for example who knows the intended feature like this back of their hand and can work directly with the developer and tester to work through the story.

2. In an not so ideal situation we don’t have these resources on hand and we can ensure that we prepare the stories to such a state prior to commitment that we can avoid the unnecessary interpretation chatter.

The first approach is a well oiled machine, it takes time to mature to a scrum like this IMO. The second approach is where I directed my attention, the critical ingredients missing were a) the Scrum master to help us implement the process properly (he was away unfortunately) and b) proper preparation of  the backlog prior to the commitment. So I made an appointment with the client to do a ‘formal review’ of the backlog near the end of Sprint 4. This is essentially the missing ceremony  – its backlog grooming  - if you haven’t heard Roman Pichler speak about Agile product management then I recommend listening to this. I call it the missing ceremony because to me it seems such a crucial aspect of sprint preparation that I would now always consider making it a mandatory activity. The net result of the backlog grooming was that I had already spent time quizzing the client about the backlog before Sprint planning and I was confident that I understood the stories and that I had already covered off many of the questions that the team would ask. This meant that less questions and queries arose during planning  (which makes estimation easier), less questions were raised at the sprint kick off and most importantly less interpretation issues came up during the sprint.

Even if you do have a well oiled Scrum I still think there’s value in preparing the backlog ahead of sprint planning and I would go as far as making this a standing part of your Sprint.

Some Favourites from FOSS4G 2009

It’s been about a month since FOSS4G in Sydney and I’ve been trying my best to not spend anytime doing GIS related stuff other than my day job – partly because my wife is sick to death of me spending time wedded to my laptop and not to her.

Anyway – I have a pack of notes that I’m just looking over and rather than writing these up inadequately I thought it would be easier to post some links to the presentations online – these are just a few of the things I enjoyed at FOSS4G this year.

• Claude Philipona – a really valuable case study on the implementation of spatial systems in the cloud.
• Mike Pumphrey – There seemed to be a lot of  (new found?) love for SLD at the conference.
• Volker Mische – Volker is an extremely talented geezer, not only was he an asset to the conference team, but his presentation was a great talking point at the event – I remember a great comment from the audience ‘just leave your relational baggage at home’
• Tim Schaub – only for the codeswarm video…. – Not being an OpenLayers developer I was very interested to learn about the protocal, strategy and format classes
• Simon Greener – It was good to be able to go back over his slides and pick out his pearls of wisdom. Simon combines years of experience and advanced presentation skills to provide a concise set of information on each slide! Not.
• Peter Fraser – Erratic and bizarre but very enjoyable

Just a taste from this years conference.

Portrait

Recently I was honored  enough to have my portrait drawn by an old friend.  It’s very accurate.

The artist is also a keen wine buff:

The final countdown…..

While the boys on the other side of the world are busting their nuts to pull the final conference pieces together, I’ve slipped away on a (pre-planned!!) holiday back home.

From Malta

Gents you’re doing a bloody marvelous job !!!