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 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.
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, 
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. »Read more of Johanna's articles and blogs |
|
||||||||
|
Safety-Critical Applications built via Agile Discipline Presented by Nancy Van Schooenderwoert on September 16, 2008 
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. »Lean Agile Partners 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. |
 |
 |