The Legend of Bruce Lee.

"Don't think. FEEL. It is like a finger pointing away to the moon. Do not concentrate on the finger or you will miss all that heavenly glory."

The man's a legend. And he epitomises the Expert. How many time have you sensed something and you were wrong? Indeed, how many times have you looked at a solution and said, there's something not quite right.

I worked on a project last year. The domain model was incredibly complex, and the calculations to derive payments to customers were extremely convoluted (based on geographical areas and the nature of borders on those areas). The business processing layer was well in excess of 100,000 lines of code. Every now and then, we'd come across a payment anomaly. A tiny amount, fractions of a penny in thousands of payments. We called it "The Bagel" because we didn't know what else to call it.

When I left it was still there, the bready, doughy ring of triggers, views and stored procedures. Its grew into such a complex mystical thing, almost always spitting out the right results. But it 'felt' bad. You just looked at it , printed out on a big bit of paper, and you knew it was bad. But you don't exactly what's wrong with it. And you know one day, it would bite you in the ass.

I just checked. Its still there. And people still feel bad about it.

That's what comes with being an expert, these things get emotional. And you don't know why.

What makes a Framework Rock?

I've been building an application to enable distributed teams to work in an agile way, and surprise surprise, I've been using Ruby On Rails. And this morning, I started thinking, why has RoR been so popular? Why have I, over the last2 1/2 years, been building all my webapps using Rails? Habit? Because it's trendy?

It's because the RoR framework enables the novice developer to pick it up and use it. Straight out of the box. The feedback loop is very short, and the rules of engagement are clearly defined - both ideal traits for novice adoption. And as the knowledge of the adoptee grows, as does the framework, opening doors (and at the same time encouraging good practice) for further learning, which in itself promotes learning.

So, to answer the question, what makes a framework rock? The framework must not only do what its intended to do, but must encourage the adoptee to want to become an expert in it, so that, with the adoptee, the framework can grow. That's how we raise the bar.

The good from the great.

One of the main things I've learned from my attendance at QCon is this.

Its not just about being bright, and having ideas. Its about being bright, having ideas and sharing them. So I've decided to write a little more about my experiences around running agile teams, and projects.

I spend a lot of time reading and formulating ideas about this subject, and as my knowledge has increased over the last few years, I have been able to become less able to justify in words why my advice is good advice. It makes me (and my team) feel good, and it enables us to deliver.

So I'm going to start keeping my musings on a more regular basis, so that when someone does ask me to write down my train of thought on my ideas, I can just point them to this blog!!

Open Sessions

The open sessions enabled QCon attendees to set the agenda. The board contained time slot for which participants wrote a meeting they want to facilitate.
I chose to facilitate a meeting on "What to do with what we've learned, when we get home." A few attendees turned up and we use a method for making a decision as a team.
It was soon realised that the things that each person had learned, was individually important to them, but as we'd come to this conclusion together, this was fine.

For me, its about being patient, and allowing change to resonate, at its own pace through the business. SO my big learning, in terms of change, is to be patient. Now I just have to put it into practice !!!

SOoooo now I'm on the train on the way back, a few things bouncing round in my head. I'll make a plan I think during my recuperation about how I can put some things I have learned into action.

In the words of whoever it was that said it, "its been emotional."

Thanks to all.

Herding Racehorses, Racing Sheep - Dave Thomas

Dave Thomas, ruby genius, founder of the pragmatic programmers range of books, speaks about the importance of recognising the knowledge in yourself and your team.

Using the Dreyfus Model as a method of understanding Dave spoke in what can only be described as a brilliant, inspiring pantomime, the levels and habits of people with different amounts of knowledge.

The importance of setting goals, rules and boundaries for novices, the criticality of enabling intuition in Experts by not questioning why, but just trusting them.

As good as he is in print. Off to another one.......:-)

When Agile Hits The Wall: Dealing with the organizational challenges of Agile adoption - Joseph Pelrine

Joseph Pelrine is the legend of all legends when it comes to team performance, working with Kent Beck on the first crack at Extreme Programming.
Since then he has become a thought leader on Sociology and Teams, and enlighten us with his knowledge on how to manage when the team hits the wall.

Joseph spoke about methods for dealing with conflicts, why agile projects fail, the importance of Apply, Inspect, Adapt, meaning that you try something, you see how it worked and then you adapt it. (a Scrum fundamental).

A very interesting and applicable presentation indeed.

Heartbeat Retrospectives to Amplify Team Effectiveness - Boris Gloger

6 Steps to facilitate more successful team learning.

Learning from the past for the future. Learning is about disappointment. We hate to be disappointed.
Disappointment provokes blaming, and stops learning.

How do we solve this paradox?

6 Step Process:

1. Security First - the Prime Directive
- "Regardless of what we discover, we truly believe that everyone did all they could,
given what they knew at the time, using the skills and resources they had to hand at the time." Kerth 2001

2. Collect (10 mins - 30 mins)

• Draw timeline, and add stickies on the timeline.....
• By putting it on the wall it is no longer your event, its a team event.

3. What went well?

• Put stickies on the board.
• Use it to raise the mood !!

4. What could be improved?

• Stickies on the board.
• Ask what needs to be done - people already know....

5. Who is in control?

• Team?
• Organisation?
• Customer?
• Use stickes to move events (what went well, what went wrong) into areas.
• The leader needs to sort these out....
• Team Backlog & Impediment Backlog - this is where these needs to be recorded.
• Publish the backlog on the wall for all to see - "Every good SCRUM master gets fired!"

6. Output
- Put both lists in ascending order of importance, and there you have your input for the next planning sprint.

• Use a dedicated room, not in the TEAM room - the environment must be secure.
• Use retrospectives for building trust in a team.
• Invite the team and everybody the team members invite.
• You get thre trust from your team by doing things for them, and removing their backlog.
• How does the company pay structure enable sharing/talking/communicating as opposed to arse covering/blaming?

Jeff Sutherland - Agile Project Management at Google

This presentation was packed to the rafters, Jeff is a god in the Agile Community.

Jeff is the father of SCRUM, spoke about how he implemented SCRUM at Google, taking principles from the production lines of Toyota into the development teams at Google, giving them their incredible momentum for pumping out applications.

SCRUM teaches people to focus on delivery in a non competitive environment, and is applicable
to all team environments, not just development teams. He covered the fact that annual performance evaluations don't work,
cost a lot of money and invariably no one ends up pleased with them. Instead he preferred continuous feedback,
in the form of one to ones and retrospectives. All Google employees have to have a web page saying what they're going to be doing over the next 3 months - they've ditched appraisals all together.
The fact that the employees have to write it down and publish their goals has created a culture of pride in making sure they complete their goals.

Jeff covered the use of a Burndown chart - a chart showing features left to build against iterations, providing a real view of functions left over time,
illustrates the importance of keeping work in progress to a minimum. Also he covered the use of change control boards, task boards and the importance of
Stand Ups and Retrospectives.


Quotes:
"Scrum is a way to get stuff done."
"Kaizen Mind - if you're not better when you leave that when you arrived, its a catastrophe!"
"He who acts spoils, he who grasps lets slip. Because the Sage does not act, he does not spoil, Because he does not grasp, he does not let slip."
"Scrum is the only methodology that makes all the issues (both personal and technical) a part of thr project".
"Most scrums are introduced bottom up."
"Team of 3 is the smallest. Any less just ain't a team".
"Challenge the teams to move beyond mediocrity".


Reading:
HBR - Creating excellent teams.
Toyota Way - Liker JK, 2004
ABC's of Scrum - Jeff Sutherland
Scrum Developer
New York Times - Toyota Training Manager

"How do we know we're done?" - Test Driven Development - Steve Freeman

Steve spoke about Test Driven Development, showing some examples, driven using the magic formula:

• Write a test
• Make it pass
• Refactor

Design is driven from how things are used, not how they are written. Development is driven with design in mind, and gives the developer continual reinforcement of success. Steve spoke of the importance of taking tiny steps, one at a time, encouraging developers to explore the space, the problem and your knowledge to deliver quality built in to the product.

Later Steve discussed the fact that TDD enables you to defer your decisions, for example giving you confidence in refactoring situations.

• Forces the developer to put themselves in the place of the caller of the code.
• Forces a fine grained modular fashion.
• Keeps them neat and clean.

Often, there are views that TDD is too much work. Some counters to this line of arguments are:

• Most of time is spent reading code.
• Include debugging time - if you get good at this, debugging time drops dramatically.
• Reliable code lets QA focus on larger issues.
• It becomes critical when you scale up - it enables you to scale up cheaply and safely - particularly around teams.

---

Reading:

TDD Yahoo Groups

Agile Project Lifecycle: User Stories and Release Planning

Presented by Rachel Davies. Rachel has considerable experience in teaching Agile Practices, having worked at the coal face for over 6 years. She is a directory of AgileXP who are based in Rubgy, Warwickshire.

Rachel spoke about the foundations of Agile methods, delivering frequently, pragmatic, not slipping on QA, making it part of the product. She covered user stories as a tool for collaborative planning, and using those to drive the development and user acceptance tests.

Rachel also spoke about the importance of a project heartbeat – for example planning, implementing and reviewing every two weeks, and the importance of a road map (not a detailed plan) to drive that. Get to Production as soon as possible…..that’s the idea.

Also Rachel covered planning releases, and for example deploying every 5^th iteration, and that not deploying every iteration won’t send you to hell. She also focused on retrospectives at the end of each iteration including the review the release plan.

Quotes:

“The goal of Agile Development is to satisfy the customer through early and continuous delivery of valuable software.”

“Welcome changing requirements, even late in development”

Agile is about people, teams and common sense.

---

 Reading: Ron Jeffries, XProgramming.com 

Agile Alliance

Agile Manifesto 

Thursday is.......Agile Day !!

The focus today is on Agile Leadership - kicking off with Fundamental Success Factors for Agile Software Development. I expect it to be a pretty packed out set of sessions. I'll update you as we go along.

Keynote - From Application to Platform - Werner Vogels - Amazon.com CTO

Werner Vogels has been with Amazon.com since the beginning, when the strategy was "Get Big Fast". This left Amazon with the most unwieldy, unmanageable architecture - the whole platform ran using one executable, with a 2 tier stateless architecture (web server, database) horizontally scaled. In its last incarnation, the executable took four days to build - making it completely unmanageable to test or fix.



In 2001 Amazon.com started to transform their architecture bit by bit into an SOA, tasking teams on focusing meeting the service specification, by any means. Some teams used Python, some Java, some Perl, Smalltalk and Ruby. However, the focus was on providing the right service for the job.



Over time, the services fell into two categories, Data Services and Aggregation Services. All in all, to serve up the front page of Amazon.com over 180 different, disparate services are called, some providing data, and others aggregating data and page information into the presentation tier.



Adopting this entirely service oriented architecture allowed Amazon.com to move into new spheres of service provision. Capitalising on their well tested (160 million customers worldwide) e-commerce platform, Amazon.com started to offer storage services, re brand their e-commerce platform and resell it - did you know Marks Spencers, Mothercare, Target.com are all powered on Amazon.com platform, hosted at Amazon.com's datacenters? Did you know that they resell all of their services, from e-commerce to delivery?



The Amazon.com platform is breaking new ground with application service provision, offering pay as you go infrastructure, in an on demand model, offering horizontal scaling at the application level (e.g only running (and paying) for 5 application servers at night, but scaling up to 30 for daytime trading) and almost unlimited storage using their S3 service.



A fascinating presentation from a serious leader in architecture. Amazon's platform is so much more than books.

QCon - Day 1 - Diana Larsen - Agile Team Building

Diana is a thought leader in the Agile World, and the author of Agile Retrospectives, a key book for guiding a project manager, team leader through the retrospective process.

The tutorial was attended my many people in the same situation as me, project managers/technical architect/team leaders/developers. Diana has an incredible aura about her, and the discussions she incited between us reminded me of that great buzz when working together as a team, and that people are absolutely key to developing good software.

The session focused on Facilitative Management (as opposed to controlling management), leadership as a role (rather than a job) and the activities of a good facilitative leader, being aware of where a team is in its "Orming" cycle, appreciating the bookends of a project (kick off meetings, retrospectives). Big parts of the session involved us sharing our experiences of where meetings/team working/team building really worked, and more importantly why they worked.

All in all an inspiration start to what is chocking up to be an inspirational conference.