Agile 2012 Development Practices & Craftsmanship stage

This is the original description we made as the producers for the Agile 2012 Development Practices Stage.


It didn't fit the needed format, so we couldn't use it, but it is what we have in our mind, and I thought it would be useful for speakers who are thinking of submitting to read.

You can submit here: http://submit2012.agilealliance.org/ 


Development Practices & Craftsmanship stage
"We have come to valueWorking Software"
This stage is about the code, and our goal is to have each attendee go away from each session having taken their game to a higher level.That's what real craftsmanship is all about - the desire to constantly improve.


We will accomplish this in 3 ways:

1. Core Practices: By having an explicit minimum set of "must have" topics  
2. Practice: we intend for Wednesday to be a code retreat day within the conference!  (more details to follow) 
3. Advanced: Agile2012 is also the premier place to share what we've learned as we've continued to improve over the last year

It should be stated that as our track is about code, we are looking for sessions with lots of code in them. Demo heavy rather than slide heavy.


Must-have
"You can't possibly have a stage for dev practices and craftsmanship and not cover ________ !" 
 That's what goes in this list for us.This stage must have an introductory session to these areas,
which we consider fundamental: TDD  - Refactoring  - Pairing  - CI  - BDD


Guidelines
Language: As these sessions are about code, one factor is which language will the demo's be given in. Please clearly state that in your submission.


No first-run sessions: Your session should be one that you've given at least once before. Even if that was just at an in-house event or for a small local group - that is ok.


Speaking skills: Help us to know what you are like as a speaker.Please include a link to a online video (preferably youtube) of you speaking at a user group or conference. This is extra helpful if you are linking to the talk you will be presenting at Agile2012, but any presentation will be helpful to us.


Training: The core goal for this stage is to transfer skill.Sessions should help people to improve their skills rather than just delivering a lecture.

Agile Open Northern California

What is Agile Open Northern California? 
[Register Here]
Agile Open NorCal is an annual, 2-day event hosted by the local agile community. Here managers, developers & students meet and discuss topics that they are interested in.
Past topics included

• Team self improvement
• Coding skills practice
• Kanban
• How to test
• Communication through drawings

Open spaces are optimized to help you learn what YOU need to, not what someone else wants you to hear.

Find out more about open spaces at here.

Who attends Agile Open Northern California?

Managers:
 There are many sessions about managing technical professionals. Agile helps to improve communication, prioritize work streams, and visibility into the team and unstick teams. Managers share their successes. Many times puzzles and games are used to help understand underlying behavioral issues.

Developers:
 There are usually hands on coding sessions to help developers practice and hone their craft. Agile development is strong on continual learning of best development practices. While Agile Open space is not language or API specific, many times the hands-on discussions are very specific to the problems you are having (For example: many times a dev will open up their legacy code challenge to solicit advice.)

Students:
 This is an excellent opportunity for students to find about ‘working in the real world.’  Also they can talk and code side-by-side with both technical managers and developers.  Agile Open is a great place to ‘try out’ ideas students have been learning in their classrooms.


Details:
Agile Open NorCal is hosted at Fort Mason Conference Center in San Francisco on

Monday, Oct. 3rd
Tuesday, Oct. 4rd

8:30 am to 5 pm.
It costs $250 to attend.  We hope to see you there.
Register Here

Open Agile SoCal 2011

What is Open Agile SoCal? 
[Register Here]
Open Agile SoCal is an annual, 2-day event hosted by the local agile community. Here managers, developers & students meet and discuss topics that they are interested in.
Past topics included

• Team self improvement
• Coding skills practice
• Kanban
• How to test
• Communication through drawings

Open spaces are optimized to help you learn what YOU need to, not what someone else wants you to hear.

Find out more about open spaces at here.

Who attends Open Agile SoCal?

Managers:
 There are many sessions about managing technical professionals. Agile helps to improve communication, prioritize work streams, and visibility into the team and unstick teams. Managers share their successes. Many times puzzles and games are used to help understand underlying behavioral issues.

Developers:
 There are usually hands on coding sessions to help developers practice and hone their craft. Agile development is strong on continual learning of best development practices. While Agile Open space is not language or API specific, many times the hands-on discussions are very specific to the problems you are having (For example: many times a dev will open up their legacy code challenge to solicit advice.)

Students:
 This is an excellent opportunity for students to find about ‘working in the real world.’  Also they can talk and code side-by-side with both technical managers and developers.  OpenAgile is a great place to ‘try out’ ideas students have been learning in their classrooms.
For students OpenAgile costs just $50 for the entire event.

Details:
OpenAgile SoCal is hosted at UCI at Donald Bren Hall (DBH) on

Thursday, Sept. 15th
Friday, Sept. 16th

8:30 am to 6 pm.
It costs $250 to attend.  We hope to see you there.
Register Here

Test-Driven Cameras

I am getting old.

The other day I was hanging around with my friend, Ike Ellis.  He told me a story about his kids.  His 3 young sons had been given disposable cameras as a gift.  These kids were actually confused by the idea of a camera that used film.  The first question they asked was

“Where is the picture?”
Ike explained that they had to look through the camera lens to see what the picture would look like.  They seemed ok with that, but the next question they asked was

“How do you know if you have taken a bad picture?”
Ike said “You won’t be able to know until after we get the film developed.” To which they replied,

“When will that be?” Still confused, they continued asking

“How do you delete the bad pictures?” 
 Ike said, “You can’t.”  At this point, the kids lost interest in the cameras.

However, because these cameras were gifts, the oldest decided to actually try out using the camera anyway.
The first thing he did was to take 6 pictures of the same thing.
Ike tried to explain that he shouldn’t do that, because the camera only had the ability to take a total of 32 (film) pictures.  After realizing that he could not experiment and would probably end up with a bad picture anyway, he set his camera next too the other two and walked away.

I wish people had this same reaction to the idea of writing code without first writing tests (TDD).

Tests give you the chance:

To see what you are going to write, BEFORE you write it.
To see if what you wrote actually worked.
To immediately get feedback.

To play (or experiment) with possible solutions.



If you haven’t already, here’s a great place to start learning to Test-Driven Development


If you are already writing tests, here’s a free library to make test even easier to write


Llewellyn Falco & Lynn Langit

Fire Programmers not using Source Control

 In our community development work we come across hundreds of good developers. Those developers rarely agree on anything. They ceaselessly debate the merits of Test Driven Development. They argue about why C# is better than Java, or Ruby, or VB. They relentlessly pontificate about the future of Cloud computing.

They all agree on 1 thing: “Use Source Control”

… Of course which source control is still up for debate.

What continues to confuse us is the lack of source control adoption in the wider development community. If everyone at every conference is pro-source control, why are there shops without it? It seems to us the reason these shops exist is because their developers are never interacting with the greater development community.  They are living in a bubble.  Does this mean they can’t be good developers?  YES!

Our industry moves incredibly fast.  To be a professional, you need to be constantly learning and collaborating with others.

The reason why source control is a universally accepted best practice is because it enables us to change code without fear, to experiment, and allows multiple developers to work on the same code base.

If your developers are not using source control; Fire Them!  If this most basic of practices is not being followed, you have hundreds more problems in your code base that are much harder to detect and fix. You have hired a programmer that is not a professional, and does not intend to become one.

Llewellyn & Ike Ellis

The value of Pair Programming

Gary Filer made an interesting comment to me the other day;

“I use to think that the value of pair programming was the shared brain”

“But after seeing you pair for the last week, I realized that the shared part is actually the waste. The value is in the differences”

The Cost of Mistakes
In my talk ‘Introduction to Agile’ I assert that the core principle of agile development is accepting that we will make mistakes, and doing things to

core agile value:

Reduce the cost of mistakes

Being an introduction talk, I only talk about pair programming from a “Knowledge Backup” point of view:

“If one of your employee’s leaves, what happens to your project?” 

But pairing reduces the cost of mistakes constantly.

What Gary was seeing was the countless times Jason or I would say “Let’s do ...” only to have the other one say, “No, your forgetting about...” or “No, there's a better way...”. Each of those times would have resulted in a much more costly mistake that was headed off at the pass.

Of course, another value of the pairing overlap comes from just looking at the mistakes.

For Example: We were doing some cleanup just the other day. Finding dead code and deleting it. Removed about 10,000 lines of useless clutter from the project, which is good. However, I probably had 5-6 times where I went to delete something that was NOT clutter, and Jason stopped me. Likewise Jason had 4-5 times where he went to delete the wrong thing and I stopped him. Together, we didn’t push any of those mistakes back to the main branch when we checked in. This is like a raided disk drive. You don’t double, you square. If I’m right 95% of the time, and Jason is right 95% of the time. Then individually we are wrong 5% of the time. But paired, we are only wrong 0.25% of the Time (5% of 5%)

In today’s world of Ctrl+Z it is sometimes easy to forget that an undo even qualifies as a mistake, the cost is so low. Agile methods endeavor to make all mistakes that cheap.

Illusions of Grandeur and Agreement

I just finished watching Adam Savage presenting at maker faire.  It’s a pretty great talk. Kinda. 

Here’s what I’m taking away:

“Set deadlines for personal projects”

But about 22 minutes in I become pretty dissatisfied, and I want to talk about why:

 I am agreeing with Adam about everything.

Everything? Yep, It ALL makes sense. I know it ALL already... Now do I believe that if I was to sit down and actually do something with Adam that everything would be great? No disagreement? Nothing to learn? 

Of course not. That’s a stupid idea. There would be tons to learn probably in the first 22 minutes. So why am I “sitting down with him now” and not disagreeing? I think my girlfriend, Lynn Langit  who happens to be a Microsoft Evanglist, said it best today:

“Evangelist seek to make everyone in the room feel smart,

 Trainers try to make everyone in the room be smarter”

This illusion of agreement is starting to bug me more and more. I don’t want to spend and hour feeling smart. I want to be smarter, but I think I’m a bit odd in this. Odd not just in the desire to learn, but in my reaction when I am, or am not, learning.

There is an interesting video from Veritasium about this.

 http://www.veritasium.com/2011/03/khan-academy-and-effectiveness-of.html

Learning involves some disagreement. So next time you are watching someone talk, ask yourself “Am I agreeing with everything?”  If you are there is probably a miscommunication going on. 

I am constantly reminded of the training scene from ‘The Matrix’:

Morpheus: How did I beat you? 

Neo: (breathing hard) You... you're too fast. 

Morpheus: Do you believe that my being stronger or faster has anything to do with my muscles in this place? 

Neo: (Shakes Head No)

Morpheus: Do you think that's air you're breathing now?

Neo: (Stops breathing hard)