JAOO Aarhus - I'm going there Monday to Wednesday

I'm going to the JAOO conference in Aarhus Monday to Wednesday - I'm really looking forward to going there. I'm reading through the program right now - there are several tracks you can follow, i.e. Cloud Computing, Enterprise 2.0, Programming Languages, Railing, Solution Track and The Odd Track.

The conference is called "JAOO Conference - for developers by developers" - I looked up Microsoft TechEd and expected to find some similar subtitle and TechEd is mainly for developers as I can see it - developing Microsoft products of course. I would love one day to attend TechEd but I have this odd feeling that it is more of a commercial event where you get a pair of baggy 10$ sandcoloured pants, a pair of ugly glasses, a blue shirt plus a Beatles-haircut and suddenly you have 15.000 Bill Gates-look-a-likes wandering around praising a single technology. Maybe it is just a good, ol' prejustice and I would love if I was wrong about this one... Which is one of the reasons it could be fun to attend TechEd just to be able to go home and tell other people with similar prejustices that they should go as well.

JAOO markets themselves as being an agile conference and the technologies and methodologies presented on the tracks are more Java and Ruby-ish than they are Microsoft. JAOO does however have presentations where you get an insight into the .NET Technology and they are also able to invite a Microsoft stars such as Anders Hejlsberg and Eric Meijer to come and tell a story or two about LINQ.

The hosts and presenters of the tracks are not the primary ressource I believe - it is the people attending who will make the conference to whatever it will look like in retrospective. I am looking forward to sit down, get to learn new stuff and perhaps talk to people about agile stuff and what each of us are working on. If you are going (what are the odds? But anyway...) drop a note and tell me what you think and what you were able to take with you :o)

www.scrumalliance.org

I came by yesterday because I was awarded a membership as part of my Certified Scrum Training and accidently stumbled across the Email with my user credentials provided after the SCRUM course. The website seems to have quite a few interesting articles - and did you know that in order to be a Certified Scrum Trainer you must pay a one-time fee of nothing less than 7400 dollars... Of course you will have to pay an annual renewal fee of 7500 dollars but then your annual membership of the website is included (a mere 100 bucks).

I don't know - I just think that's a lot of money for having a reference to somebody who have an idea that you know something about Scrum. Anyway - I think I want to check out the site and read some of the articles. More to come later - if you know of other Scrum communities worth checking out please let me know  :o)

/ K.

Define user satisfaction

Quote from Software facts and Fallacies by Robert L. Glass - page 133:

"A user will be satisfied if he gets a product that meets needs, is available at an appropriate time, doesn't cost a fortune and is of reasonable quality".

We had a couple of real world users testing the website that we have been building for the past 3-4 months. I noticed a few things walking around yesterday evening while they were testing:

• Nothing crashed. I never had users come in to test any of my code on an entirely new website without anything crashing with an ugly ASP.NET stacktrace showing up.
• Nobody gave up and needed a lot of guidance help to complete their testing. There were a lot of questions of course and quite a few logical errors but people seemed to have a basic understanding of what they were supposed to do to keep moving forward.
• 4 out of 5 questions could be solved with a textual changes / graphics instead of written text or layouting the page a little differently. We could really use a dedicated tester which knows something about design and usability in our team.
• Nothing is as painful and as to see users revealing stupid logical errors. In Denmark we usually write the zipcode and the city on the same line: "7100 Vejle". We had an inputfield, some 30 characters allowed but we had clientside validation which threw an error if you entered any non-numeric value or more than 4 characters (all zipcodes in this country consists of max. 4 numeric characters. Small country, you know...). During our own day-to-day testing during development we had always just entered the 4 numeric characters which would pass validation check - and we would gladly have put this in production if users hadn't pointed out our own stupidity to us in advance.

As the wise men say: "You learn the most by your biggest mistakes". Point taken - we had a few things to correct. And - given the quote from above: We actually delivered something the users testing our system felt was useful - we tested on the night scheduled a month ago - we haven't spent more than a few months developing and it provided a solution to our Product Owners problem. How about that? :o)

Regards K.

Process change only works top-down

Recently I have researched a bit on how to make a SOA project succeed - and much importantly: Why SOA projects fail. Given that the best way to make speed is to avoid making errors uncovered by others a Google search for "SOA Antipattern" reveals all kinds of goodies.

There are a lot of repeated do's and don'ts around many of which are quite obvious. For one: "Don't dive into a SOA project with a Big Bang refactoring of all your infrastructure". Agile chapter 1, page 1 (perhaps page 2): Don't do big refactorings at all. There is no such thing as a big refactoring if you have committed to the agile way of doing software development.

But: There is one argument which isn't quite so obvious and can be counter-argued with theoretically. The argument goes that the owner of a SOA business case should be a business executive in the area that the SOA service should be serving. Why is that? Well: For one: It commits the business to take responsibility for the IT they want, a.k.a: Having the business own it's own IT business cases stops having IT delivering good, stable and reliable products which doesn't solve any problems.

Having experienced a bit of problems lately in our Scrum process I came to think that there are a few similarities between the two. You need the business present on a daily basis taking responsibility of the development of the product you are about to deliver. The key elements which are critical for the Product Owners to be mentally involved in a Scrum team are (in my opinion):

• Force the Product Owner to come to your Daily Scrum. No excuses - they must show up and listen to what you have to say. They might not understand everything but the team needs the Product Owner present to ask questions and for guidance.
• Speak their language. Never say "This feature sucks because it requires me to make serious changes to moduly Y and X" but "That sounds like a neat feature- and it will unfortunately take X days and hours to implement". They don't understand technical complexity but the PO has a deep respect for "Return on Investment" which means the time spent on a single feature by the development team.
• Make them test every time you commit something to the mainline /staging environment. No excuses. If the PO haven't tested an implementation the PO can't say it is Done and your team haven't improven the velocity of the sprint.

By following these steps you know that the Product Owner knows what's going on and can be held responsible for - well - IT projects that doesn't solve any problems in the business domain ;o)

The best way to ensure that the PO does in fact adopt to these few guidelines is to not let the IT departement drive the Scrum process. It can't be stressed enough. Any kind of process change and mindset change must ideally come from the Dark Knight of Evil, a.k.a the president of your organization. If i.e. SCRUM is only implemented within the IT departement you never get the Product Owners to adopt your philosophy because the live in a different world with a different mindset than yours. That mindset might not leave room for i.e. half an hour of testing when the Scrum Team says something needs to be tested. It is probably not because the Product Owner doesn't know or can't see the value of testing - but if the Product Owner is being overruled and assigned other priorities by his/her boss the SCRUM process fails because the team is unable to show progress to the rest of the business.

It's all a matter of prioritizing time - the SCRUM team and the Product owner needs to have the same priorities and only the Dark Knight of Evil mentioned above can reassure that the priorities are the same for various Product Owners and the various development teams within an organization. That's why the biggest antipattern in my opinion when implementing SCRUM in an organization is to let a single departement drive the mindset change through. It'll never be a good experience for all parts and inevitably the SCRUM process will be questioned again and again.