In-the-SPIN: Newsletter of the Boston@SPIN
 Issue 59 Summer 2009
Editor: Abby Fichtner 
In This Issue:

  Beautiful Teams by Andrew Stellman
  Management-Mandated Multitasking by Johanna Rothman
  Where Does Developer Testing End & Tester Testing Begin?
Fichtner, Oster
  Infrastructure for Agile: Reach for the Clouds by Mario Moreira
  Running Effective Daily Standups by Dan LeFebvre
  Connect to Your Audience by Claudyne Wilder

We hope you enjoy these articles from our wonderful presenters and roundtable facilitators over the past quarter. Remember the Boston SPIN is on summer vacation July & August but we'll be back with a great new line up in September. Have a terrific summer and we'll see you in the fall!

Signed, The Boston Spin Volunteers
Beautiful Teams book Beautiful Teams
   by Andrew Stellman
Beautiful Teams Presentation by Stellman & Greene

In April, Andrew & Jenny presented on Beautiful Teams, the topic of their wonderful new book. Here, Andrew follows up with some of the insights they learned about what makes a team beautiful...

One of the challenges of working on a book like Beautiful Teams is coming to grips with the sheer breadth of information and ideas. The more we spoke with others about their own experiences with beautiful teams, the more it became clear that there were four distinct "buckets" these conversations fell into:
  1. People - Who's on the team
  2. Goals - What brings them together
  3. Practices - How they build the software
  4. Obstacles - What gets in their way
Summer Vacation!
Boston SPIN is out for summer

Watch our website for the September meeting.
Stay In Touch
Connect with other members:
» LinkedIn Boston SPIN Group
» Twitter use #bostonspin

Got more to share?
Blog about our presentations or roundtables and we'll link to you in the next In-the-Spin.
@ Email Us Your Blogs!
You Might Also Like...
Agile Teamwork: People Issues
Johanna Rothman,
   Steve Berczuk,
   Ellen Gottesdiener,
   Mike Dwyer
Agile Bazaar, 07/23

Real Distributed Scrum & Agile
Andy Singleton
Agile Boston, 07/29

Agile (audience choice)
Jeff Sutherland
Agile Bazaar, 08/06
Two of my favorites quotes from the book use the metaphor of digging holes in the ground. The first is from Steve McConnell, one of my favorite software writers, who talked about establishing an elevating goal for a project:

"If you're out digging ditches, that's not very elevating or inspiring. But if you're digging ditches to protect your town that's about to be attacked by an enemy, well, that's more inspiring, even though it's the same activity. And so the leader's job, really, is to try to determine or frame the activity in such a way that people can understand what the value is."
What Are You Saying
About Beautiful Teams?

A Beautiful Teams Evening
» by Johanna Rothman

Beautiful Teams
» by Abby Fichtner
The second is from Scott Ambler, whose books and articles on software process have consistently helped me steer my projects over the years:

"You can't always tell when a team is dysfunctional. If there's negative shouting and screaming, that's a problem. But sometimes, you can be on a team where everyone's trying, but nobody's communicating, and nobody's reaching their goals. The easy analogy is that during the day you've got people digging a hole, and at night other people are filling it up. Everybody's working really hard digging and filling holes, but in the end nothing of value is actually occurring."

I like these quotes in particular because they're not necessarily about software development but speak to some basic truths of working with teams.

» View Andrew & Jenny's Presentation
» Read Andrew & Jenny's Beautiful Teams

Transitioning to Agile: Solving Problems of Transition (Roundtable)
Management-Mandated Multitasking: A Common Pitfall of Transitioning to Agile
by Johanna Rothman
The team is working in time boxed iterations, delivering working releasable product at the end of each one. Sometime around iteration 9 or 10, when the team has hit its stride, management says,
"Hey, Agile Team. We need you to do your magic on this other project over here."

The team says, "Sure, at the end of this iteration."

"No. We want you to work on both projects at once."

What do you do?

Never Say Yes
Saying Yes is a guarantee that you will fail. Instead, consider these strategies:

Shorten the iterations. It's possible management needs to make decisions sooner than your iteration's length. If you're using four-week iterations, reduce them to two weeks. Then, management only has to commit to something for two weeks at a time.

Manage support work differently. If you have support work (which often cannot wait), maybe you need a support team with rotating membership. Each iteration, remove people from the creating-product team, and have them do support. You change who those people are each iteration to share the support load evenly.

Integrate support into the backlog. Maybe you don't need an entire support team, but you have some support issues that arise every so often. As part of your backlog, add a few cards for "unknown support work" and give them story points, so you have reserve time for support.

Consider breaking your team in two to work two projects "at one time." If you have a larger team, say 8 or 9 people, break them into two smaller teams, one assigned to each project.

You could also insist management start managing their project portfolio. But that's fodder for another article! Whatever you do, don't just blindly accept more simultaneous work or projects. That's not a recipe for success.

» Read more of Johanna's articles on her Managing Product Development blog

In Agile, Where Does Developer Testing End and Tester Testing Begin? (Roundtable)
Where Does Developer Testing End and Tester Testing Begin?
by Abby Fichtner & Nate Oster
If Programmers are testing their code, what are Testers doing? How is there time for testing in a 2-week iteration?

These questions all assume some big hand-off from the programmers to the testers. But in agile, we all work together towards the same goal, rather than handing off from one group to the next. Here are some ways testers and developers can work together to build quality into our software:

Drive Development from Acceptance Tests. Have testers work with the product owner to define acceptance criteria for each story before coding starts. Have them define tests that must pass for a story to be "done."

Pair a Programmer & Tester on Each Story. Testers create an objective definition of "done" by defining tests that must pass. Programmers code functionality and help automate tests. Testers do exploratory testing and refine test scenarios with the programmer, allowing programmers to fix issues in real-time to gain immediate feedback.

Hold Everyone Accountable for Quality. Hold programmers responsible for internal quality through clean code backed by automated unit tests. Hold customers responsible for defining their conditions of satisfaction. Have testers help customers articulate quality needs and work with programmers to ensure all quality needs are met.

Build a Safety Net with Automated Tests. Use automated tests to validate the software several times per day to enable the team to proceed with confidence as they evolve the system.

Adopt a Stop the Line Mentality. Continually inspect and adapt to ensure problems are caught and fixed immediately, before any further work is able to build upon them.

Demo Production-Quality Software to Customer at end of each Sprint. Frequently check in with the customer to ensure the software is fit for purpose and that the team is moving in the right direction.

» Join Abby & Nate for their workshop on this topic at Agile 2009

Modern Approaches to Infrastructure: On Premises or In the Clouds (Presentation)
Infrastructure for Agile: Reaching for the Clouds
by Mario Moreira
Given that when applying Agile, you start coding almost immediately, how do you get the infrastructure set up quickly? Some projects use an Iteration zero for infrastructure tasks, but even then, the time and effort required to establish your infrastructure can far exceed the time it takes to start development on an agile project.

The good news is that today there is a new option available to companies that don't want to spend considerable time and large amounts of capital to establish and host their infrastructure locally. This new option is renting "Infrastructure in the Clouds." The infrastructure game has been changed.

Renting infrastructure in the clouds is a more recent concept and option where organizations are utilizing infrastructure (servers, software, etc.) in the internet cloud. This service is sometimes known as cloud computing but has a variety of other names each with different focuses including software as a service, application service provider model, platform as a service, and application infrastructure provider.

A distinct advantage for Agile teams is that the cloud infrastructure approach enables users to use only what they need, something directly in line with lean thinking. This "use what you need" approach minimizes infrastructure debt and allows the product team to scale to their need in a just-in-time manner. An additional advantage is that it helps minimize upfront capital expenses since you don't have to buy hardware, software, and other components. Effectively the infrastructure (e.g., servers, software, etc.) becomes more of an operating cost (pay per use approach).

This may be just the solution needed for those companies envisioning the next wave of innovative products so they can focus less on the infrastructure and more on taking their ideas to the next level!

» View Mario's Presentation
» Learn more about infrastructure options in Agile Journal: Infrastructure - on Premises or in the Clouds

Running Effective Scrum Meetings (Roundtable)
Running Effective Daily Standups
by Dan LeFebvre
Almost all agile methods include a practice called the Daily Standup Meeting. However, there seems to be much confusion about the purpose and usefulness of these meetings. Many people believe the daily standup is a status meeting for the ScrumMaster. Others feel it's an unwelcome interruption to the flow of their work.

The real purpose of the daily standup is for the self-organizing team to check in with each other to make adjustments as needed to meet their iteration's commitment. Here are some tips for running effective daily standups:
  1. Limit the time to fifteen minutes.
  2. Pick a regular time to meet, preferably in the morning, and start on time, regardless of who is absent.
  3. Have each person answers these three questions:
    a) What have you accomplished since the last meeting?
    b) What are you working on next?
    c) What is slowing you down?
  4. Sometimes ask a 4th question "On a scale of 1 to 10, what is your confidence that the team will meet the sprint commitment?" Discuss all answers ranked below 8.
  5. Hold it at the task board or with the electronic board open.
  6. Promote self-organization by having the team lead the meeting.
    SM should stand in the back, not at the task board, while team members update the sprint burn down.
  7. Encourage people to add tasks to the board when new things come up.
    This makes the task board (sprint backlog) the official record of the sprint.
  8. Keep an impediments list on the wall. And use it.
  9. Use a talking stick or marker if there are many interruptions during the meeting.
  10. Defer all discussion and problem solving until after the meeting and follow-up as needed in smaller groups.
Connect To Your Audience (Presentation)
Connect To Your Audience
by Claudyne Wilder
Everyone wants to keep the audience engaged while looking and sounding confident and in charge of the information. Here are some specific ideas on how to do that, courtesy of Claudyne Wilder, author of Point, Click & Wow! The Techniques and Habits of Successful Presenters:

Channel Your Nervousness
» Practice out loud -- do a real rehearsal
» Make sure presentation is the right length
» Really look at your audience & see their interest
» Breathe and relax as you talk
Motivate Your Listeners
» First two minutes, connect to your audience
» Change the pace with your voice, gestures, slides
» Tell stories that relate to audience's interests
» Dress the role
Manage Questions
» Tell people when to ask questions
» Repeat the question if audience could not hear it
» "Briefly" answer the question
» Answer the question to the whole room
Conclude With Conviction
» Rehearse your ending
» Keep a confident voice
» Have an energetic stance
» Conserve your energy so energetic at the close
» View Claudyne's Presentation
» Learn more and sign up for monthly Presentation Points at Wilder Presentations
Software Engineering Institute | Carnegie Mellon
SPIN | Software Process Improvement Network
With thanks to our sponsors...
MKS   BigVisible  The MITRE Corporation  Rally Software Development Corporation  Chaco Canyon Consulting  AccuRev, Inc. A TurnKey Website  Flatbread Company