Øredev 2010 - Day 3 - Tristan Smith

Keynote - Dr Jeffrey Norris - Mission Critical Agility

Having shared a naked leap into the ocean after a sauna with Jeff, then chatting to him over dinner we felt a special connection with him. He gave a fantastic keynote, covering three key parts of Agility.
Vision, Risk and Commitment
He illustrated vision by talking about Alexander Graham Bell, inventor of the telephone. The environment of the time was one of a total monopoly by Western Union with the Telegraphs. The problem with the technology was that it was single message only, WU had snapped up all the available inventors to work on a multiple message telegraph.
Into this came a wealthy benefactor wanting to break that monopoly by inventing the multi-message telegraph first, without access to a big pool of inventors he snapped up Bell. Bell, whose father had invented a method of teaching deaf people to speak wanted him to take up the family business. The benefactor had a deaf daughter who Alexander taught to speak (and got romantically involved with).
Despite the pressures he faced, he kept working on his vision with  it eventually resulting in huge success. Interestingly, Bell's research into the telephone was based on a mistranslated document, he had read that someone had successfully changed sound to electricity and based on that belief managed to find a solution. It turned out that no-one had done anything of the sort.
RISK was illustrated with the Moon landings, NASA were working on a couple of methods of getting to the moon. The popular option was just to have a huge rocket that flew there and flew back, simple! The alternative option was raised which involved building a 4 part rocket which would involve space walks and multiple separations in space. A much more complicated solution, a much riskier one and yet it was the one they went for, and successful too. Vision and Risk.
Factoid: While the rocket was on the ground, it was the largest building in Florida, then they launched it into space!
COMMITMENT While we're constantly reminded of the risk of change, there's also the risk of failing to change as shown by the Western Union example. Holding back critical investment until after evaluating multiple routes and holding back as long as possible can increase agility.
Failure on a followed route can lead to other routes that may be successful.
"Leave the beaten track occasionally and dive into the woods - Graham Bell.
I have not failed. I've just found 10,000 ways that won't work. - Thomas Edison.

Take Control of Your Development Career - Michael Norton

The key to Doc's talk was, figure out what you really love and take control!
If you follow the points below:
Get noticed, Get together, Get your Mojo on, Get Naked, Get schooled
Get Noticed
Learn your business so you're better able to solve problems, you can get better insights into other problems that can improve efficiencies too.
When you're looking to move on up, don't forget to DO your job. You need to be recognised as a good worker in your current role before being elevated to another you're focussed on getting.
Make yourself expendable (so you can be replaced in order to move up and out of your role).
Get Involved
Join a user group, they're a great place to encounter new ideas. If you help out with a user group or even start / run one you get much better visibility. You can then contact the types of people you'd never get a chance to other wise in sourcing speakers for your user group.
Get your mojo on
Improve yourself, get your Koans and Katas on, hone your craft. Build something non critical but important to you as a great way to learn in a non contrived way.
Get Naked
Run with people who are better than you, it's much easier to improve when you're the lowest in a group than the highest, otherwise it can lead to laxity.
Use something different for you (set up a CI box, learn a new language).
Admit when you don't know.
Get Schooled
Find a mentor, attend conferences, teach a new language or subject (your commitment is a great motivator to learn that new subject).
Finally, Get Started!

Tightening the feedback loop - Patrick Kua

Where as with software development TDD and Continuous Integration gives us instant feedback, feedback with people tends to be done on a longer timescale.
Personal reviews tend to be yearly. Yearly feedback makes it somewhat irrelevant, it needs to be done after significant events so that it can help avoid paths that shouldn't be taken and fix issues early.
Giving effective feedback should strengthen confidence or improve effectiveness feedback shouldn't be about you as a person and you shouldn't be thinking 'How does this help me at all?'
It's important to create a feeling of safety so the person is open minded to it. Give feedback in private, ask if it's the right time. Can I give you some feedback? Is now a good time?
A good feedback formula is - Specific time, observed behaviour, perceived impact, "Let's discuss", suggested solution. For example "Yesterday when pairing, you laughed at my solution, I felt belittled and upset."
Giving Feedback
Give feedback earlier, create safety, focus on behaviours, not too much, make it a conversation
Receiving feedback
Rule #1 Ask for Feedback
Rule #2 Don't be defensive
Rule #3 Seek clarifications
Rule #4 Say thanks (Positive reinforcement loop - drive culture of feedback)
Rule '#5 Take action (Not acting on feedback will lead to a lapsing of confidence in giving feedback at all)

Clarity means Completion: The Psychology of Kanban - Jim Benson

Kanban column headings called Value streams they're the steps you take to provide value.
Existential overflow - The capacity to work while stress increases.
Tasks that are left uncompleted leaves your brain spinning. This is called the Zeigarnik effect.
The less control you have over the flow of tasks, the greater this effect.
Seeing tasks flow across the board helps lessen the effect.
Metacognitiion is the layer which analyses how you learn and what impact that has..
Connect and Clarity
Pulling a backlog task onto the limited WIP makes that a valued task to the person pulling it. This can lead to thoughtful pulling where the impact of a given task is evaluated and prioritised. The investment can make that person's task's progress  more important and the fixing of issues that hold it up along the way more important.
In this way Kanban depersonalises the workflow, if there's a problem, it's not just Bill's fault it's personal investment in the processing of a task. The relationship to work changes this way.
The morning stand up which is scrum is often zombie like, where if you're lucky you tell everyone something they didn't know this can be transformed into a task based one where the focus is less on what you did and didn't do and more on where tasks are blocked.
Kanban works on a number of levels, one of which is that it rewards the brain in a number of ways.
The brain loves it when there's no blame, it loves collaboration and it loves pattern matching.
The context of work Todo / Done makes a value map. You can see the things that were valued by those done, people can take pride in the tasks done and it can increase respect.
Developers range from people with ADHD to Asbergers. Kanban changes from individual focus to flow. It makes it easier to spot a task taking a long time so where the Aspergers type is focussed on perfection you can see that immovable task.
The goal is to get tasks done and off the board.
There's a clear definition of done, if the post it is on the right and hasn't moved in a while.
Tasks with happy faces show nice tasks vs bad ones which can show the subjective mood at any time. Retrospectives - why did this suck, can we fix it?
There's a Kaizen impact (continuous improvement) due to the real time fixing of issues (sorting of problems found).
There's some Kinesthetic feedback too with the tactile feedback of moving post-its.
The moving of post-its has a parallel with child raising where picking a task and moving it through the different stages is like birth, growth, pain and release where each task is a plot point.

The developer who played with XAML - Jeff Wilcox

A pretty average session, added a few notes below but I mostly wrote up other notes in this session.
Silverlight 4 gets inline properties
<Button><Button.Content>Hello!</Button.Content></Button>
Suggestion of dropping attributes onto new lines to make Source Control changes more obvious.
Avoid triggers (designers can't figure out triggers, VSM is a replacement for this)
Always do Static Resources over inline styling.
Putting curlies in strings requires "{}Hello {user}a".
Really bad error messages are as a result of a transition between managed and unmanaged code.
Dictionary improvements to xaml in SL 4 make it possible to create objects dictionary style in xaml.
obj > debug generated files are in there which can make it easier to debug issues.
Attached properties - Canvas.Left, Grid.Row where they only apply if relevant.

Agile Release Planning - James Shore

If you're not paying attention to the business success factors as well as the technological ones, you're going to fail.
Reality on the ground compared to the beautiful plan can be very different.
He used a real pre-planned holiday that went wrong for him with a partially planned holiday with flexible activities. There's a win for adaptability with late defined plans.
Minimum marketable features
The minimum deliverable marketable value.
Deliver value not technology, deliver the most valuable features first.
Releasing these features means you can start making money sooner.
Build an entire vertical slice at a time to allow the MMF to be built, not a 3 tier method of writing Data Layer, then Business Layer then UI.
Avoiding "The Grand Plan" and just working on feature incremental design and architecture means as you go you can change the direction for better paths, it makes you more agile. The idea being that you avoid "The Grand Plan" being twisted over time with new features and changes.
Working this way can also reduce waste.
Dividing the tasks into Vision, MMFs, Stories and Tasks gives you a range of time and ordering to the level of detail required at each point. This lets you plan in a more general way further out but more specifically closer in.

The Burning Man - David Prior

A session covering a number of the failed or dysfunctional projects David had worked on in his career.
As a reader of The Daily WTF I'd read stories about similar situations to the examples he gave, it's always useful to learn from mistakes so this was an interesting if somewhat incredulous talk at times.

He gave examples with multiple project owners fighting, half hearted scrum, PMs not passing on accurate progress reports such that the client believes everything is still on track. Teams of unqualified developers without any action being taken to rectify it. Backend systems handled by unreliable people with no progress updates and monitoring. Alcoholic employees who were geniuses when sober.
The cause he had found in almost all of these cases was fear. Fear of repercussion, fear of failure, fear of being fired.

The titular Burning man example was a disaster because the backend system his company was due to integrate with was being handled by the client's CTO. The CTO had just sold his stock for millions and taken his developers to the Burning Man festival 4600 miles away two weeks from the test date (and they wouldn't be coming back for 5 weeks). When David asked for the code, he found that for that entire year the CTO and his devs had 0 lines of code.

His solutions included daily introspectives and failure focussed brainstorming.
The failure excuse model can be identified by things such as "So. I can't [do this thing] because [obstacle] won't let me." and "I want to [do this thing] because [reasons] and I can't because [reason]".