Links to share with your friends and co-workers

1. Is an Agile PMO possible? – Curt Finch talks about the values of both Agile practices, PMI standards and how to marry the two.
2. Self-organization: the secret sauce for improving your Scrum team – In this 90-miute video for Google, Jeff Sutherland talks about the role of self-organization and other advanced Scrum techniques.
3. The Agile Flywheel – a short experience report describing how one company melded Scrum with their mature ITIL processes.
4. Just do it: a quick intro to Agile’s technical practices – a summary of the technical core of Agile software development by Abby Fichtner.
5. I love pair programming – Discussion on the effectiveness and the challenges of pair programming after a five month trial.

Excellent links for everyone to share.

1. Pollyanna Pixton on Agile Leadership – a 30-minute video talking about the factors corporate leaders can influence which support Agile teams.
2. How I Learned to Program Manage an Agile Team After 6 Years of Waterfall – Sara Ford describes in brutal candor her experience becoming an Agile PM while working on CodePlex at Microsoft.
3. Explaining Agile – Mike Cottmeyer neatly summarizes his understanding of Agile.
4. How to Compare Elephant Herds - Dave Nicolette finally (?) explains why comparing teams through velocity is meaningless.
5. What Does a ScrumMaster Do? – for those of  you who are curious and wanted to know.
6. Replacing the Iron Triangle of Project Management? – short discussion on reevaluating a well-accepted PM paradigm.
7. Adopting Agile Development – the Role of the CIO – how senior leaders in your organization can help promote Agile adoption.
8. Moving Beyond Scrum – a look at some reasons why one might want to take the next step.
9. Tragic Mistakes When Adopting Test-Driven Development (TDD) - Scott Ambler discussing some pitfalls & obstacles companies encounter when they begin the process of using TDD.
10. Comparison of Open Agile with Scrum – introduction of a domain-independent framework for delivering value while using Agile principles via a compare-and-contrast with Scrum

Here are some links to the best of the blogs since the beginning of the year.

1. The Role of Leaders on a Self-Organizing Team - Mike Cohn talks about the important role management continues to play on Scrum teams.
2. Agile Scales, Waterfall Doesn’t – or so claims Vasco Duarte during this 48-minute video from the Agile Eastern Europe 2009 Conference.
3. Scrum, But – in this 10-minute video Scrum co-founder, Ken Schwaber, explains the negative impact on your business of “We use Scrum, but…”
4. Management 3.0: The Era of Complexity - Jurgen Appelo describes the new role of social networks as management dives into the 21st century.
5. Faster, Better, Cheaper! TDD wins in a simple experiment – a side-by-side comparison of two software developers working on the same project – one using Test-Driven Development (TDD), the other not; the developer who used TDD increased his productivity by 50%!
6. Agile Game Interview: Simplicity is Hard - Clinton Keith interviews Chris Ulm, CEO of Appy Entertainment, about why Agile is an essential factor in their successful launch of high quality, iPhone games.
7. Embedded Collaboration - Dave Rooney kicks off this post with a classic quote from “The Princess Bride” to explain the real meaning of collaboration.
8. Agile Office Space – the Motley Fool shows off their cool Agile workspace and describes the principles they used to create this space.
9. Wives of Rockstar San Diego Employees Have Collected Themselves – apparently some people are fed-up with yet another death march in the gaming industry and interesting from commentary from Clinton Keith that Scrum is not the solution, but provides visibility and a reality check to wishful thinking.

Just wanted to reiterate the value of TDD – I am working on a programming challenge and was surprised how easy it was to add a hunting and killing algorithm to my program.  Since it was written using TDD, I had a nice suite of fast tests which allowed me to incrementally encapsulate my new algorithms and keep the system functional at nearly every step.

At the most, I only had two, maybe three, broken tests while adding the new classes, pulling up fields and moving methods.  Not bad, not bad at all.

… they are too short.

Mark Levison has posted an interesting article, Making TDD Stick, on InfoQ that covers some of my observations about how to sustain test-driven development (TDD) in an organization.  I have found the best way to teach TDD is to mentor\pair with an individual one-on-one until they “get it” (about 4 to 6 weeks).

Unfortunately, one-on-one mentoring is not feasible or economic as bigger organizations try to improve their quality with TDD.  There are just not that many self-proclaimed TDD experts out there.  To solve this scarcity issue, often times big companies bring in a TDD expert to provide classroom training for the 40 or so developers deficient in this skill.  Once the trainer has been scheduled, the participants are rounded up, sit in a one or two day class, the consultant gets their check and then nothing happens!

I have not seen the model of flying in a training for a one or two day training ever work.  Why?  People do not know what to do after the trainer leaves.  TDD is hard and makes highly skilled (and highly paid) professionals feel like morons.  After a day of flailing about in their IDE, most developers jettison the whole thing and walk away with the idea that TDD only works on “toy projects”.  Not surprising since that is all they saw in their training – an easy-to-understand and easy-to-teach example that fits within the confines of a day.  Little guidance or no guidance is provided on how to apply the TDD concepts back at your desk.

What is my alternative?  Make the class longer – about two to three weeks.

1. Week One – Basic TDD training (up to 1 day) followed by 4 days of practical application.
2. Week Two – Advanced TDD concepts (up to 1 day) followed by 4 days of practical application.
3. Week Three (optional) – Five days of practical application and mentoring.

At the end of each day, I gather all the team members together for an afternoon show-and-tell of all the tests they wrote.  Everyone is required to show at least one test.  The purpose of the discussion is to learn where people are having trouble, who needs help from the trainer, what is working for the developers and allow people to express their frustrations.  The daily retrospective amplifies the learning and allows the teams members (or the trainer) to make mentoring connections among themselves.  At least you now have a fighting chance to make TDD succeed instead of people suffering alone at their desk hating life.

Spanish has an interesting word to explain the concept of “excessiveness” or “too much” – demasiado.  It can be used to talk about things, such as “Tenemos manzanas demasiadas”\”We have too many apples”, but interestingly enough it can also refer to people, as in “Él es demasiado”\”He is [just] too much.”

Today, Jeff Attwood was talking about how you can do too much logging in an application.  I know exactly where he is coming from because I was once told to implement the type of logging he describes in his post.  I found the usefulness to be about zero (well…not exactly zero, but more on that later) and they cluttered up my code with something worse than comments.  IME, this type of logging comes from a development environment where people spend more time in the debugger than they do writing tests.  If you have a system described and constrained by tests, you really do not spend time using the debugger.  In fact, I use the debugger so rarely, in order to use the debugger, I need to look up on the Internet how to use it or I need someone to show me.  Talk about feeling foolish – a developer with over 8 years of experience and I don’t really understand how to use the debugger, but that is life.

Why?  Because if I have a problem, I can debug through my tests or just hit Ctrl-Z enough times and get back to a “good place”.  The times when I reach for the debugger are the times I am lost in my own code and I find I just need to step away from the keyboard.  The desire to use the debugger becomes a warning I need reconsider what is it I am trying to accomplish, return to first principles and take smaller steps.  When you are lost in your own code, you need these trace statements sprinkled everywhere to understand what is going on.  When you need to debug your application while it is running, because you have not spent the time to unit test the application during development, these statements are essential.

Now for the obligatory ancedote that highlights a glaring exception to my dogma: I was once working on an application where I was the only developer using TDD and we were having the application fail during system testing.  Not just any part of the application, but MY part of the application.  The part implemented doing TDD, so it couldn’t be MY part of the app that was failing.  Unfortunately, it wasn’t clear why the app was failing from the exception logging, so our architect had us turn on the trace logging.  The root cause of the failure: a method of mine was being fed an empty string that I did not anticipate.  Bad me that I did not guard against an empty string; good me that I can now write a unit test for it & prove the bug is dead.  So where did the empty string come from, a part of the application that didn’t have any tests.  My fellow developer never considered an integration test where his part of the app talked to mine.  Just proves yet again that if you want to find defects in your application, look for the parts that don’t have tests.

“Test-driven development [TDD] is dual-entry bookkeeping to prevent errors in your code.”

I was lucky enough to see Uncle Bob give a presentation on TDD this week.  During his demonstration of the Bowling Game, I noticed he refrained from writing tests for the all the little helper methods he extracted during the course of the test-code-refactor cycle.  In the past, I had a tendency to take these private methods, make them public and write tests against them.  Something never felt right doing it, but it never hurts to have more tests, right?

However, after watching Uncle Bob, I understand why you don’t need to do that: the original method that spawned all the little helper methods is already well-tested.  If there was a defect in the private helper method, the public method will inform you.  Intuitively, I knew that and was beginning to go there.  Uncle Bob just moved that process along faster, so thanks!