In-the-SPIN: Newsletter of the Boston@SPIN
 Issue 60 November 2009
Editor: Abby Fichtner 
In-the-SPIN brings tips from our presenters and facilitators to help us apply the great things they've shared with us at our Boston SPIN meetings.

In This Issue:

  Agile: No Converting Necessary by Damon Poole
  Code Stability Metrics: Identifying Good and Bad Code by Fiona Dossin
  Relationships: The REAL Goal of Networking by Marilyn Santiesteban

We hope you're enjoying our SPIN meetings. We've got a great line-up for the 2009/2010 year including Tim Lister and Ed Yourdon. And we're always interested in your voice -- would you like to facilitate a roundtable? Are you blogging about our meetings? Have ideas on how we can improve? We're here for our members, so drop us a line and let us know what you'd like from your SPIN.

Signed, The Boston Spin Volunteers
 
Is Agile Any Better? (Presentation)
Damon Poole Agile: No Converting Necessary
by Damon Poole

What's your favorite flavor of ice cream? Most people prefer Vanilla, but Chunky Monkey is pretty popular these days too. A lot of people think Agile is like that -- the new flavor of the week; preferred by cowboy coders and folks who take unprofessional shortcuts that won't stand up over time.

But if you look deeper, you'll find that Agile is a discipline with a whole body of knowledge behind it. Just look at the many books written on Agile practices and I think you'll find many of its practices are worthwhile in their own right.

You don't even have to be Agile to use them; most can be adapted to traditional projects:

• Continuous Integration
• Unit Testing
• Backlog
• Time Boxing
• Daily Standups
• Refactoring
• Product Owners
• User Stories
• Collaborative Teams
• One Piece Flow
Next Meeting
Developing Career-Enhancing Persuasion Skills
Naomi Karten, 11/17
November Roundtables
Creating Effective Corporate Decision Processes
Bill Weinar

Needs & Leads!
Networking & open discussion
Stay Connected
Connect with other members:
» LinkedIn Boston SPIN Group
» Twitter use #BostonSPIN

Got more to share?
Blog about our meetings and we'll link to you in In-the-Spin.
@ Email Us Your Blogs!
You Might Also Like...
Scrum & Kanban:
Chocolate & Peanut Butter?

Damon Poole
ScrumClub, 11/19

Give Thanks for Scrum
J. Sutherland, K. Schwaber,
S. Augustine, Amr Elssamadisy
Agile Boston, 11/24

Helping Geeks Produce:
The Pillars of Coaching

Mike Hill, Agile Bazaar, 12/3

Rightsizing Your Project
in a Down Economy

Michael Mah, SQGNE, 12/9

Each of these practices provides value in and of itself. But their value gets magnified as you add more practices because each one makes the others easier to do and reinforces their value. If you add in ScrumMasters, short iterations, iteration demos and retrospectives, you'll achieve critical mass, adding a whole new level of value.

You don't have to "convert" to Agile. The goal is to find new and better ways of doing things, not being Agile. What would be the point of adopting Agile if it was just a matter of preference? That would be like me trying to convince you that Chunky Monkey should be your new favorite flavor of ice cream. Instead, consider trying some of the practices. Even if you don't call them Agile. I bet you'll find that not only do you like some of them, but that they provide significant benefits both for the business and for you personally.

» View Damon's Presentation
» Read more of Damon's tips on his Do it Yourself Agile blog
What Are You Saying About
Is Agile Any Better?


Ways Agile beats Waterfall
» by Dan Modello

First Takes on Boston SPIN
» by Matt Heusser

Software Stability Metrics: How To Find "Good" Code and "Bad" Code (Roundtable)
Code Stability Metrics: Identifying the Good and Bad Code in your Projects
by Fiona Dossin

The ability to identify Good vs. Bad code gives development organizations valuable insight into the health of their code base. Insights that can be used to evaluate software quality, determine where additional resources may be needed, and identify potential risks before they turn into problems:

  • Good [Stable] Code works well and causes few issues.
  • Bad [Unstable] Code can cause numerous project issues and eat up valuable resources as it demands more and more time for fixes.
Code Stability Metrics examine two components to determine stability (or "goodness"):

Volatility represents how much effort is required to maintain the code. Common measurements include the number of check-ins or lines of code changed. Tracking volatility helps us identify which parts of our software require more development effort.

Quality represents how well code is designed and written. Common measurements include Cyclomatic Complexity, conformance to coding standards/practices, and number of bugs. Tracking quality allows us to see if our quality is increasing or decreasing as our product evolves.

For example, we might chose # of Check-Ins (Volatility) and Cyclomatic Complexity (Quality). Since a lower value is preferable for both, we can compute a project-specific Stability Score by multiplying the values together:

File # Check-ins Last Month
(Volatility)
Cyclomatic Complexity
(Quality)
Stability Metric
(Lower is Better)
Class A 10 10 100
Class B 5 5 25
Class C 20 15 300
Project Total 425


Here, Class B is the most stable, Class C the least. So, we might decide to focus on increasing the stability of C, which will in turn improve our project's overall stability. As Class C's volatility decreases, so too will the amount of development effort required to maintain it.

Tracking stability metrics allows organizations to identify problematic code before it becomes a real problem.

» Learn more about Stability and other Code Metrics on Fiona's blog

Systematic Networking (Presentation)
Relationships: The REAL Goal of Networking
by Marilyn Santiesteban

It's happened to all of us. We attend a networking event with the goal of making new contacts. We talk to as many people as possible, diligently gathering business cards. We mean to follow-up to build these new relationships, but life intervenes. A week later, we run across a stack of business cards and can't even remember who was who, or which person we promised what to.

While we had the best intentions, potential connections too often vanish before they have a chance to get started. What can we do differently?

Set a Goal for Yourself. Are you looking for leads in target companies? People in certain kinds of positions? Three new leads? Be specific and strive to achieve it.

Ask for Business Cards. Jot notes on the back to help your remember -- about the person, what you talked about, and what you agreed to send them ("new to management, big ERP deployment, forward article on metrics").

Give Out Your Own Business Cards. Even if you're unemployed. List your name, contact info (no address), LinkedIn URL, and your top three skills.

Follow Up Within 24 Hours. This is the real secret. Send emails to everyone -- the folks who sponsored the event, the speaker and everyone who gave you their card:
  • Send thank you notes
  • Send anything you said you would (or a note that you're working on it)
Expect that most people will respond promptly, but recognize that some won't. Don't be discouraged! Wait a few days, and then send another note. Frequency is key. Relationships require nurturing. Make sure you keep in touch at least monthly. One-shot contact rarely yields a sustainable connection.

Try it out at the next Boston SPIN meeting!

» View Marilyn's Presentation
» Meet up with other networkers in Marilyn's Create the Opportunity Network for job seekers
Software Engineering Institute | Carnegie Mellon
SPIN | Software Process Improvement Network
With thanks to our sponsors...
MKS   BigVisible  The MITRE Corporation  Chaco Canyon Consulting  Rally Software Development Corporation  A TurnKey Website  Campaign Monitor  Domino's Pizza