map butcher

This morning I had the pleasure of having breakfast with Martin Fowler. (Note that there were about another 200 people at this breakfast).

Thoughtworks hosted their quarterly briefing this morning with Martin Fowler and Andy Marks presenting “Agile-Adoption - How to stuff it up”

Its an interesting time in my current project, and not unlike many other organisations we’re starting small, adopting a few key technical practises, and trying to operate in stealth mode.

It was an interesting discussion, which touched on a number of key issues which cause agile adoptions to fail. Not a complete set, but perhaps some of the more common reasons:

• Underestimate change
• Assume minimal cultural impact
• Learning finishes at school
• Let other people fail - we’ll take it from there
• Experience is overvalued
• De-emphasize techncial design

I took away a few notes from the breakfast which resonate because of our current project. Fowler opened the presentation with a short blurb about the roots of Agile and talked particularly about adaptive planning and the people first approach. Its the latter that really makes me want to adopt agile. It’s the opportunity to work with and develop a great team of quality people that excites me.

Of course ‘people over process’ is part of the Agile Manafesto, but I sometimes forget how important the people in our team are in helping to deliver this project.  It was also good to hear about issues that we’re directly experiencing; what Fowler described as the ‘early pain principle’ and failure. They sound horrible, but as I discussed previously they’re not always negative things. Tomorrow morning is my third sprint retrospective - I’m planning not to fail.

In the coming Sprint we need to re-focus on technical design, its important to understand when you’re code base is beginning to run away from you and its been a bit like that in the last week. I’m hoping to take stock in the next Sprint as well as use our progress to date to develop our design in certain areas. This to me is a priceless benefit of Agile. My initial design no longer cuts the mustard - no surprises, so we’ll address that.

Andy Marks delivered a great presentation, but it was a point made during Q&A by both Fowler and Marks which really stuck in my mind: Trust is such a vital part of Agile, we have to trust each other - the team, the customer, everyone involved need to have trust for a project to succeed - again its the people that matter.

Presentations submissions have now closed for FOSS4G 2009, and I’ve just generated a wordle based upon the submitted presentation tags. As you can see it’s picking up some interesting themes already, cloud computing, the environment, mobile, business and participatory - as well as the good old stuff too…GIS,  Spatial, Open etc. We’ve received over 170 presentations from all over the globe. The presentations make up the back bone of the conference and we’re looking to cram in as much variety and quality of content as possible - you can play a role in this to…read on.

So what happens next? Well there are a few things you may want to know about:

1. If you have already submitted a presentation and would like to have this considered for the academic track then you can log in via this page and flag your submission for consideration

2. If you are attending the conference or thinking about attending then you will very soon be able to view all the submitted abstracts and vote on them. We need your help as we unfortunately don’t have room for all the submissions. THIS IS YOUR CONFERENCE TOO so keep an eye on the FOSS4G 2009 website for more details on how to vote (note the voting will not include academic submissions)

The following is a summary of key dates for those interested in the conference presentation content:

• General Presentations open for voting:  14th June - 28th June 2009
• Academic Track - Full Paper Due: 29th June 2009
• Notification of Acceptance for General Presentations & Academic Track: 20th July

The early bird registration is open till the 31st July  - go on click the link and come and join us in Sydney

**UPDATE** academic abstracts are now accessible for public voting

I’m working on a project at the moment which is using SCRUM.  So far I (and hopefully the team too) think it’s going well despite the occasional FUD that you hear about the place, sometimes this can be distracting but I keep telling myself that we’re getting a return from the process and those responsible for the FUD are just clinging to their safety raft (albeit one usually full of holes).

Taking on any new process, SCRUM or otherwise is a challenge and it’s this challenge together with the complexities of the project which makes days like today really engaging. I’m really tired and I feel more committed to the project than ever, but the odd thing is that today started with a failure.

Today was our Sprint Retrospective. I had to demonstrate the working software that we’d committed to in the last sprint and it failed - this was not as bad as it first may sound because there were clear reasons why the software was failing:

• Items on the sprint backlog were not well understood by the team (me in particular!). 
• Project dependencies were not well understood prior to the Sprint planning taking place, which meant we’ve learnt many of these dependencies during the sprint and had to adapt to these
• We need to bring testing into the sprint
• We need to be careful when adding new items to the backlog during the sprint  - asking the question “can the sprint deliver the software as committed to without this item?” is a useful way to eliminate unnecessary items creeping onto the backlog
• ‘Work in progress’ occured during the sprint and remained once the sprint was complete. 

However there were many positives from the sprint too, we came close to achieving the sprint goal (close but no cigar), we’re working well as a team and we all have a role to play in the process and the projects success. We’re getting better at estimation, at examining the items on the backlog, at adapting to change, at working toward a defined goal and these changes and improvements are occurring quickly.  Today was an early failure, and not one that was exposed beyond the product manager (although IMO its not necessarily a bad thing for a client to see these failures too, especially if they’re actively involved in the SCRUM). We’re not late, we’re not over budget, we’ve just seen an early failure. In the space of a day the failures have  been examined, dealt with and we’ve already got the next sprint backlog in place ready to go.

We don’t want to fail as individuals or as a team, but we’re not fearing it. Instead we’re actively working together towards addressing the issues and demonstrating working software at our next retrospective.

A few days ago I decided to change the way I was developing my current solution. I am creating a WCF service and had started out with a standard class library, but hit some issues in terms of regularly building an installer and deploying the libraries onto a test web server. To address these issues I decided to implement the service as WCF web service, rather than a class library and utilise a web deployment project to control the build and deployment, this worked sweet until i noticed that my custom tracing was not working.

A  number of hours passed while i tried to get an understanding of where my trace had gone. Was it permissions? Was the trace configuration not defined correctly? Why was the debugger skipping over the  trace statements? arghhh - where’s the f***ing fax machine…

I am making calls like this:

LRSLogger.Instance.TraceEvent(TraceEventType.Verbose, 1, "LocationManager.processLocation: Creating LRSDAOFactory");

Where LRSLogger.Instance is a System.Diagnostics.TraceSource.  If you look at the TraceEvent method you’ll notice it’s decorated with:

[ConditionalAttribute("TRACE")]

Which indicates to the compiler that this method call should be ignored unless a specified conditional compiler is defined. It turns out that when hosting the WCF service within the ASP.Net development server (or IIS), ASP.net does not compile trace statements by default.  I’m unsure of why this is the not the case with a WCF Class library? So to overcome this issue I updated the web.config for the service as below:

    <system.codedom>
<compilers>
      <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" compilerOptions="/d:TRACE"
                type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">  
      </compiler>      
    </compilers>    
  </system.codedom>

…and now the compiler includes the trace statements and I get my trace log back. Lovely Jubbly

Francis Bacon's Studio - A prolific workshop

I grew up in the North East of England living next door to a guy called Ken who had a workshop. Everyday Ken would go out into his workshop with his cigarette and cup of tea and make stuff. He worked in their all day and every now and again me and my Dad would pop in to see what work he was up to. Sometimes he’d be turning wood on the lathe, other times he’d be under the hood of a car - but he was always working. I always liked a little box which hung on his wall, the box had a glass front and to one side a small hammer. On the front of the box  were the words “Break in an Emergency”  - inside the box was a single cigarette and a match.

Ken is not around anymore but if I were to see him today and explain what people have done to his beloved workshop he’d be disgusted! You may feel the same way, you may have heard a phrase similar to this ‘let’s workshop it’. And that my friends is where the problems begin.

The term ‘workshop’ like many other terms, which litter our daily working lives has been bastardised. Workshops are where work is done.  So here is my list of advice for anybody think about ‘workshopping it’

1. DONT. Your office, work place etc IS your workshop, it’s where you work. You don’t need to specially convene a shop to work in. You already have it. 

2. Think about what you want to achieve before you decide to ‘workshop it’ - it may be that you want to convene a meeting to gain an understanding of an issue facing your project, perhaps a Birds of  Feather may be appropriate. You may want to have a dedicated session to actually resolve a known problem then perhaps we can borrow the idea of a sprint to achieve this?

3. If you must  ’workshop it’…..then elect a leader. Lack of discipline is a major reason for ‘workshops’ degenerating into a quagmire of opinion. An authoritative, informed and focused leader can vastly improve and add value to a workshop (or any meeting for that matter). 

4. If you must ‘workshop it’…..then invite only the bare minimum of useful bodies. IMO if you find yourself in a ‘workshop’ with more than 5 people you’re in trouble. Its very hard to get meaningful and valuable contributions from a large group.  A useful way of evaluating whether you have got the right people is to ask each person directly what value they are bringing to the table - what work are they planning to do in this workshop? If they can’t answer this question something, somewhere has gone wrong.

5. If you must ‘workshop it’……then do not accept on face value the phrase ‘I think this has been a successful workshop’. 9 times out of 10 this is not true. You can only assess a successful work shop by evaluating the work that has been done, and to do this you must have an expectation of the work to be achieved at the outset.

Ken, my next door neighbour never broke the glass case for the cigarette. He never needed to, as his workshop produced work (and he always had several full packs of cigarettes!). All too often in todays ‘workshops’ the glass is broken and the cigarette smoked long before the work is complete.  Resist temptation.