My Overview of Agile Presentation (to a local PMI Chapter)

I was invited to give a talk about Agile to the Delaware Valley PMI Chapter on January 7th. The audience was going to be filled with local PMP's, some of which would be skeptics, and some of which would have been burned by bad agile implementations. I was worried about how to normalize their knowledge, and I had to do it in less than 45 minutes so there was room for Q&A.

Once I realized that I couldn't cram Scrum, XP, Lean training in along with a proven case study... I decided to go for the overview and provide them what they needed to find out more. I wanted the group to understand the Scrum is Agile, but Agile is more than Scrum.

As far as I can tell, the session was a success. I got positive feedback at the end, and I felt I made the most of our time.

If you want to get a copy of the slide deck, you can download it here. Since I'm not that popular of a guy yet, hopefully this won't overwhelm the daily bandwidth limits of my personal website traffic restrictions. If you get nothing, email me or put a comment on this post and try again tomorrow (and I'll have to move it to another host).

Having been through this experience, if there is anyone in the Philadelphia region that is interested in having me come talk about Agile or some specific piece of it... feel free to contact me. You can find many ways to reach me on my personal site.

Quote Series Part 5 - Code

This is part five of the series, to see what this series is about, click here.

Quotes on "Code"

Code degrades naturally, it needs refactoring constantly - ObjectMentor coach

Treat the system as a growing organism... failing tests equal the need for a behavior modification - ObjectMentor coach

Always check it in in a better state than you checked it out. - ObjectMentor coach

Don't let code sleep - things happen while you're asleep. (tests must pass on "sleeping" code) - Tim Ottinger

Switch pairs whenever you need to, it is not an insult but a way towards knowledge transfer and efficiency. - ObjectMentor coach

Refactoring: A series of small steps, each of which changes the program’s internal structure without changing its external behavior - Martin Fowler

Code left unchecked-in for a week is like milk unrefrigerated for a week. Eww. - James Shore

By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback. - Kent Beck

Reading other people's code is the best way to learn. - Uncle Bob Martin

The mere presence of a great source control system doesn't obligate anyone to use it in a structured, rational way. No. That takes discipline - Jeff Atwood

Architecture without executable code is just an hallucination - Ivar Jacobson

Best code = non existent code - Amit Rathore @ Lean Kanban 2009

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

NFR's and Technical Debt...

Two reposts due to their interesting topic and unique content:

1. Non-Functional Requirements, a minimal checklist at Leading Answers. This is a good checklist for any team to work with their product owner and cover all that "technical stuff" that insures the product's success or failure outside of its features. Some people call this the "-ilities" list.
2. Using the Mikado Method to pay down Technical Debt. This is a good post that uncovers the typical lesson of refactoring the guts of a ball of mud. For every thing you fix, you find 10 more. The Mikado Method is a good way to plan out refactoring to avoid this problem.
   

TAD vs. TDD vs. paired TDD

This is a repost from Jeff Langr where he simply models how TDD is quicker than TAD and paired TDD is quicker than either of the first two.

Simple but effective.

TAD:
CCCC xxxx TTTTT xxx IIIII RRR II

TDD:
TCTCTCTC xxxx IIII xxx RR I

Paired TDD:
TTCCTTCCTTCC xxxx xxx

Confused? Read the full version here.

Commenting your code...

I once heard a very wise man say... if you comment your code, that is an apology for its lack of readability.

Okay... so that might be an extreme viewpoint, but still a good philosophy.

If you want a more balanced view, Tim Ottinger blogged about 3 rules for comments today.

I like.

Dale Emery has spoken...

For whatever reason, Dale Emery blasted out a whole pile of blog posts this morning (update: he just modified his blog structure which caught up the feed!). I started to follow his work after attending his "Resistance as a Resource" session at last year's Agile Conference in Toronto.

Two of his posts stood out because they discussed how to approach a technical system and think of it as a planned response system. He goes on to define system responsibilities, essences, events, and obligations.

The definition a system’s essence makes no mention whatever of technology inside the system, because the system’s essential responsibilities would be the same whether it were implemented using software, magical fairies, a horde of trained monkeys, or my brothers Glenn and Gregg wielding pencils and stacks of index cards.

In a second post in the series, he goes on to discuss the anatomy of responsibility further. Both are good reads, and I encourage you to check them out.

Staying on the Dale Emery kick for the day... I also enjoyed his post about "testing as an information service." He focuses on the quality assurance and testing team roles and how they affect the surrounding team.

Testing is an information service. The point of testing is to inform stakeholders about the system. This is not a new sentiment, nor does it originate with me.

He goes on to tell a story about one student in his class and how he realized the goal of his role is not to rub developer's faces in found bugs, but to inform the team and stakeholders equally of what is broken AND what works as expected. Testing is a litmus test, not a contest.

hmmm... I'm going to repeat that last one again and stake claim to the quote... "Testing is a litmus test, not a contest."

TDD is good...

Most of you probably follow InfoQ and have seen the recent article referring to the study showing that TDD improves quality. The data seems to show that it is 15-30% slower to develop using TDD, but the defects seem to decrease on the magnitude of 40-90%. Most managers would agree that the defect savings would more than pay for the increased cost. The study had very comparative control subjects, so the data should be considered valid. A peer of mine mentioned that this type of TDD was not as mature as could be, and therefore would imply the gap might be even bigger with TDD mature teams.

Also, Mike Bria made an attempt at creating an elevator pitch to pronounce the values of TDD. His pitch is a little longer than my typical elevator ride, but it is a good explanation for those techies looking for a better understanding.

Permission is not needed!

Over the last few years momentum has increased around the agile movement. It goes by many names (Scrum, XP, Lean...) but they are basically pointing at the same core inspiration: allow the team to be part of the decision making, quality, and accountability chain.

Typically people on the bottom have felt abused by the old system and latch onto this new system. Some test it successfully, and others yearn for more time to learn. Either way, the secret eventually escapes about their activities.

And then the dirty question rises: How do we convince the business to let us keep doing this great thing that increases our morale, quality, and predictability but is not easily quantified in the old world of thinking.

This is where I get confused. Since when did developers lower themselves to a blue collar status. Your job isn't to punch widgets, or flip burgers and assume that every break is clocked and pre-approved. We are a college educated group of people that bring a disciplined skill to our environment. Nobody asks the artist to make the artwork in half the time... only the artist can dictate how long it will take to do their work. Why are developers different?

Alan Cooper's keynote at Agile 2008 spent a lot of time talking about how the software process is more like a trade or craft than an engineering process that can be tuned like a factory. This was his foundation to explaining why usability needs to be incorporated. Here's an expert telling us..."Own your work!"

Then one day later, Uncle Bob presented a keynote that clearly stated the same point again... "Own your work!" His initial summary was craftsmanship over crap and led to a standing ovation of 2000 people which are all leaders in the agile movement.

Today, Tim Ottinger talks about fear of refactoring, TDD, and doing it right and tries to answer the question yet again. He also reposted from the XP mailing list a quote from Jame Grenning :

There are two values to software
1) Business value delivered
2) Ease at which the next important feature can be delivered

There is a theme here folks... quit asking for permission and own your work.

I've always struggled with the existence of the permission question for two reasons:

1. I started my career as a developer with a computer science degree and feel I can relate to the issues developers are going through today (though it has been 8 years since I wrote any real code)
2. I spent more than 5 years as a usability engineer. This role forced me to constantly justify the time and science behind this craft to insure I was allowed to do my job correctly. I was fighting against the mentality of developers that user interfaces had to be built with intention and to the business that this process was cheaper than not doing it.

So, I've always had to defend my craft. I've always had to sell my worth. And because of it, I've been successful at reaching my career goals.

Once again, I find myself pointing to the keyboard and saying get back to work and do your job the way you know you need to. Stop letting them make you compromise so much. Prove to them why you are so valuable and stop marching according to their defined instruction. Be the expert at how to do your job and manage your craft!

Now, go forth and quit asking this silly question.

Note: before you take my advice, become a maverick , and get yourself fired you should probably read J.B. Rainsberger's paper from Agile 2007 about "My Greatest Misses: XP"

Local Build... how big and how long?

Peter Morlion raised an interesting topic on the Agile Alliance LinkedIn group about how long a developer build should be allowed to run. It seems his team is split down the lines of "its important, so suck it up" and "this delays me too much, make it better".

His full question was:

Local build takes a while - run a stripped-down version?
Like in a lot of teams, we update from the source repository, change code, run the build locally, and commit if it builds. So far, so good. But the build takes a while of course. Personally, I think that's just something to live with, but my teammembers want to use a stripped down version of the build (mainly not building the sandbox, because it doesn't change much).
What is your opinion on using a non-complete build before committing, while the build server still runs the full build?

As one of the first to answer I said:

I would agree with your team members... unless I already need to take a smoke break every hour or so, that does not enable higher productivity. ; )

In my last team, the local build included the tests... If your developers have to wait more than 2 minutes for the process to complete, they start seeing this time investment as an impediment and may try to work around it by coding larger chunks before committing and integrating. This is the reverse direction agile maturity typically should take a team (especially a team leveraging TDD).

The sooner someone can verify something in the integrated build server, the better off the team will be. The purpose of the local build is to smoke test the local and obviously connected things they are focused on.

A balance has to be created between the two. If you swing too far in the other direction, then the team is hurt because the integrated build is broken more often.

Good luck finding the happy medium.

Code reviews?

Alex McMahon has a great post about the appropriate time to do a code review. Some very great questions and some very interesting proposals.

I wanted to leave a comment, but "you must be logged in". So, I'll put them here.

• Why does your code review take so long? Should it?
  
• Pair programming, though very effective and valuable, is difficult to sell or get working properly... but why can't review be a rotating thing. Spread the love, normalize your review approach.
• There are several comments in the post skirting the testing topic, but nothing blatantly stating it. Tests should pass first, then check in. If the tests pass, then any refactoring caused by the code review should be easier and lower risk. This safety net will allow you to check in first and then do the code review second.