In-the-SPIN: Newsletter of the Boston@SPIN
Issue 57 Winter 2008/2009
Editor: Abby Fichtner 
Hello, Boston SPIN Members and Guests!
We hope you're enjoying our Boston SPIN meetings. We've kicked off the 2008/2009 year with a fantastic line up of presentations:

• Nancy Van Schooenderwoert showed us how organizations are successfully
   using agile in Safety-critical applications,
• Michael Mah shared productivity comparisons of Agile vs. Waterfall,
• Johanna Rothman coached us on how we can be better coaches,
• Tom Zauli taught us how to tame the SOA beast in our organizations.

And, we're extremely excited to bring back the newsletter! We want to keep you on top of the latest in software process improvement and help connect you with others in the industry. If you're blogging about our meetings, let us know and we'll link to you in the next In-the-SPIN so you can share your thoughts and ideas with the community. Boston SPIN is all about you, our members, so please don't hesitate to email us what you'd like from your SPIN.

Signed, The Boston Spin Volunteers

Boston SPIN Presentations
Building Your Coaching Skills
Presented by Johanna Rothman on November 18, 2008
Sometimes, you're in a position where you feel stumped. You know the problem is solvable, but you don't know how. If so, Johanna Rothman you might be looking for a coach.

Sometimes the coaching is for two minutes or less, "How do I tell my boss his fly is open?" Sometimes, the coaching is for longer, as when you see a pattern of problems in the organization and want to help solve them. But not every problem you see is a cause. Sometimes, the problems are effects of other problems. In that case, learning how to ask questions that articulate the problems can be quite helpful.

At the November SPIN meeting, I had an opportunity to speak a little about coaching and then facilitate some practice among the attendees. People had some great conversations. I wrote up some of those conversations in one of my recent email newsletters, The Problem Statement is not always the Problem.

Remember coaching is a time-bound collaborative relationship based on trust. You can be a great coach. I practice being a coach by asking for coaching, and by practicing all the ways, not just teaching, that I can coach.
»View Johanna's Presentation
»Read more of Johanna's articles and blogs

Next Meeting
A Strategy That Beats Recessions and Prepares You For the Better Times Ahead

» Curt Van Emon, 02/17

What Are You Saying?
Are you blogging about our meetings, speakers, or roundtables?

Let us know and we'll link to your blog in the next In-the-Spin newsletter!

@ Email Us Your Blogs!

Next Roundtable
Common mistakes when implementing Agile and Scrum

» Peter Toudjarski, 02/17

You Might Also Like...
» Deploying Your Agile Toolbox Gradually,
Igor Moochnick at
Agile Boston, 01/28

» The Nitty Gritty of QA Project Management,
Carol Perletz at SQGNE, 02/11

» Testing the Untestable,
Robin Goldsmith SQGNE, 03/11

» Deep Agile 2009:
Agile for Embedded Systems,
Agile Bazaar, 04/24-04/25


Safety-Critical Applications built via Agile Discipline
Presented by Nancy Van Schooenderwoert on September 16, 2008
Nancy Van Schooenderwoert At the September SPIN meeting, we discussed the discipline that is central to agile software teams. Because agile discipline is misunderstood, many people assume it's non-existent and therefore that agile is inappropriate for safety-critical applications. We covered:
• Intersection of Safety-critical practices and Agile team practices
• How "agile" and "discipline" go together
• What real agile teams are doing now

Agile is characterized by software practices that keep us grounded to technical reality along with management practices that keep us continually in touch with customer's needs. Team ownership of estimates and design decisions is key. This requires special skills to achieve optimal group decisions and carry them out.

We took a look at three safety-critical medical products built using agile teams. One company makes pacemakers, with the programming device for them built by an agile team. Another offers radiology images for diagnostics and treatment planning via the web. Image quality and ability to retrieve the correct images for a patient are must-haves for this company's service. A third company provides medical imaging products that do 3-D rendering, making images available over the web.

Each of these companies said that before their move to agile, they delivered high quality products by doing whatever extra rework it took to achieve the necessary quality levels. But after their shift to agile, they achieved the same high quality at far lower cost because they prevented problems rather than paying to fix them later in the process. They also said that the most difficult things were getting used to the "agile culture" of team autonomy, and picking themselves up after their early mistakes. No one wants to go back to their pre-agile ways.
»View Nancy's Presentation
»Lean Agile Partners

Roundtable Discussions
Agile Methods: Dogmatic -vs- Pragmatic
Facilitated by Steve Berczuk on October 21, 2008
At the October SPIN meeting, we had a roundtable discussion "Agile: dogmaticism v pragmaticism" where we discussed what is necessary for agile practices, and what the risks of being overly dogmatic are. Some of the more interesting ideas that came out were: Agility is about being pragmatic and adapting, so if you are overly dogmatic, you are not being agile. Also, that it's important to follow a process for a time before you adapt, as becoming agile involves change, and people tend to revert to the usual, familiar ways. Once you know what's working and what is not, you can then feel free to adapt.
Software Engineering Institute | Carnegie Mellon
SPIN | Software Process Improvement Network