Achieving Success with Distributed Teams

On February 28, Josh Woodcock gave a presentation on his experience working with a fully distributed team and shared ideas on how agile can be successful in such situations. Even though Josh’s team is spread across the US, they have been able to create a virtual team room and share information by using video and online tools. Team members use webcams throughout the day, making them feel more connected to one another and promoting the type of osmotic communications found in physical team rooms. Team members also pair program by sharing screens.  By asking the question, “how would you handle X if the team was co-located?” Josh’s team has been able to find and use online tools to replicate as much of the co-located team experience as possible.  For many distributed teams that are struggling, using tools to ends up feeling like this:

That’s not how we’d want co-located teams to be, so why settle for that experience when we’re distributed?  Consider how something would work well for a co-located team and find the tools that work to support your team’s communication throughout the work day (suggestion: use video as much as possible and limit emails—rely on richer, synchronous communication when you can).

In Josh’s experience, finding the right tools to support his team has resulted in high-quality and frequent delivery of working software that delights their customers. For more information about the presentation, including a list of recommended tools, view Josh’s slides at

Since this topic had such a high interest from our members, we continued our discussion in March with an open space format.  We started off by sharing ideas and questions that we had and then formed smaller groups based on the following subtopics:

  •       How to effectively run the scrum ceremonies and communicate between ceremonies
  •       How to divide work
  •       How to handle cultural differences with the team
  •       How can the team support the Scrum Master and Product Owner

The discussions were lively, and each group reported out its findings.

Gaining Support for a Sustainable Agile Transformation

Mike Cottmeyer, LeadingAgile co-founder and President, visited us in January from Atlanta to talk Mike Cottmeyer Professional Head Shotabout sustainable agile transformations.  In fact, just days before his visit, he asked if our group would like to see the presentation he gave at conferences earlier in the year or if he could skip the slides and share his latest thinking—we opted for the latter!

Mike sketched his thoughts and talked ad-hoc for an hour and a half about what executives really want from a transformation (predictability), how most coaches and consultants “sell” or push for something else (culture change), and how a company’s business model may be at odds with an emergent, innovative, agile model.  It was a very engaging and thought-provoking evening.

The talk took incorporated ideas from Mike’s original presentation on Gaining Support for a Sustainable Agile Transformation and ideas from the blog posts he wrote that week.  It was a great meeting, and thank you again to Mike for sharing with us!

A strong finish to 2013

We had a great year in 2013.  Thank you to our members for suggesting the topics, facilitating and presenting, and participating in DFW Scrum month after month.  Our goal is to help you do better today than you were doing yesterday, and the best way to do that is through the collective wisdom and experience of the crowd (sprinkled with some industry experts).  Our last three meetings of the year exemplified our goal and values.

September: DEV+QA in the same sprint – how’s it possible?

Dave Nicolette led the group in a discussion of how the magic of getting dev and QA to work close together and complete their work within the sprint happens.  Challenges can come from large stories, unclear or missing acceptance criteria, multiple product owners, and a lack of automated testing.  These challenges are quite common, and the beauty of our user group is that we can rely on the wisdom of the folks in the room to share their experiences and successes!  Spending time refining or grooming the backlog so stories are smaller, the requirements and acceptance criteria are better understood, and even writing the acceptance criteria to be testable can be helpful.  Teams that move to behavior driven development (BDD) do all of that while also building automated tests.  The magic is that QA spends time helping to clarify or reveal the acceptance criteria, which the developers need to know in order to write the software—the relationship between dev and QA becomes closer with this mutual need, and the delivery of stories within a sprint becomes easier.  That’s the magic.

October: The Science Behind High-Performance Teams

Peter Saddington, CST, visited us from Atlanta to talk about the behavioral science, neuroscience, and psychology behind high-performance teams.  Self-organizing teams are made up of individuals, and each individual has certain behavioral patterns.  These behavioral patterns can be identified using various assessment tools, and knowing the behavior patterns of individuals can be extremely helpful in forming teams because they contribute to the team dynamics.  What does someone love to do?  What types of problems do they enjoy solving?  How do they know they’ve done a good job at something outside of work?  The answers provide insight into a person.  A strong team includes diversity.  Teams should also have fun together.  Executives don’t ask to increase fun in their organizations, but happier people are more productive and innovation increases.  The biggest obstacle to fun in most organizations is multitasking or context switching.  And if you require your team members to work on more than one project at a time, you put quality, speed, and value at risk.  Leaders should be “lovers of people” and “inspiration starters.”  Slides are available here.

November: Using Agile Outside of IT

We had 3 of our user group members share stories of how they use agile frameworks and practices outside of IT—Jennifer Nusbaum in an educational registrar environment, Tony Akins at home to write a book and mow his lawn, and Ty Crockett at home with his family to do household chores and his son’s school project.  Each presentation reminded us of some of the core concepts behind agile and scrum: how a backlog provides visibility and focus, how iterative and incremental work can get the job done, and the importance of reflecting back on how we can improve for future projects.  It was our first time having multiple presentations at one meeting, and it was quite successful!  We would love to have more members volunteer to share their experiences like this.

What did we forget to say about these meetings?  Comment and let us know.

Empirical Process Control


​In Scrum Training, I started touching on the difference between the “Waterfall” method of project tracking (Defined Process Control​) vs. Empirical Process Control​. At the root of the Waterfall system is the idea that for the same inputs into a system, I can expect the same outputs and that the work ahead of us is well defined and known. In software, that usually is not the case, as we really don’t know that what we have built is what the customer wants until they can “experience” it in the way of working software. The other idea with Scrum is that we focus on getting the teams so disciplined in the logistics of shipping software, that is no longer the pain point or hold up in the process, we can ship software when we want (which to me is the definition of “Agile”).  

It is easy to get caught up in the “logistics” of a process and just focus on the mechanics, I think this article by Barry Hawkins does a great job conveying more of the “why” behind Scrum. If we can focus on the ideas and principles of the process, we can use that as leverage to get better instead of saying “these are the ceremonies in Scrum, go do them”.
There is another article that brings good insight into how people have turned waterfall into something it wasn’t originally intended. I bring this up as I regularly speak to University students regarding Software Development approaches (typically traditional SDLC is the first process they learn). They were in awe of the article I show on Dr. Royce’s “Managing the Devleopment of Large Systems​“. Fig 3 of the Waterfall process shows iterations are recommended. He describes the traditional SDLC model in Fig 2 inviting risk and failure. Dr. Royce’s paper is great and offers a great perspective on a big problem we were trying to solve in the 70′s. We also seem to always be in a rush and sometimes miss what an article was trying to convey. Thus began a formal process that the government originally initiated to help “control” projects.
To sum this up, I love the diagram below (provided by Ralph Stacey). When people ask “when should we use Scrum”?, I display this diagram and say, “anything past Simple are best suited for Scrum” (although I would still use Scrum on the simple ones as well). If any process involves humans and creativity, it is automatically a “complex” project in my humble opinion.

Sail or Fail? Navigating Test Automation Pitfalls


Paul Grizzaffi joined at DFW Scrum last night to go over the topic above. Too often, automation has to be justified and bought into before we spend resources on it. I like how Paul compared it to an Insurance Policy. No one likes to pay for insurance unless of course the tornado takes your house down or the car is totaled. Look at automation in that it will save us from potential catastrophes and customer implications of bad software. However, unlike insurance, automation can make us more efficient and “Agile” at the same time.

I like to say that being “Agile” in software development, simply means that you can ship software when you want. If a feature was demo’d and thought it was good to release to customers, could you do it? Or is it a lengthy / painful process to push code from our developers’ machines to production?

Automation is definitely a specialized skill set at this time, we all know it would be better and a good idea to do, but how do we go about doing it? Paul’s message was clear that you can’t template an approach to automation, but he can share with you some good practices / questions to ask. Other valuable lessons are what NOT to do.

Quality is everyone’s job, automation is everyone’s job. How do we fit it into our development processes? Paul’s presentation is available for download, check it out and  hit him up for questions if you have any.

Quick take-aways

  • Don’t try to automate a broken process (garbage in and garbage out)
  • Must know your process and job before you can automate
  • Think of your automation as a safety net / alarm system (confidence in making changes)
  • Test cases are your contract between the requirements and the interface
  • Try not to change Test Cases for your automation unless the contract changes
  • Automation is an insurance policy, you want a high deductible you get low cost (risky)
  • Discuss automation in context of opportunity cost (not ROI)
  • A human used to do x now its automated they can go to y
  • Exploratory testing is opportunity cost, computers are good at repetitive tasks, humans are not

Upcoming Meeting and Giveaways!

via Kevin Geary

via Kevin Geary

I was fortunate enough to meet Peter Saddington in Nashville at the Agile 2013 conference, and a few of our members and I enjoyed his session on “The Science Behind High-Performance Teams” so much that we invited him to present the same topic to DFW Scrum.  Not only did he say yes, but he’ll be coming to Dallas in person to teach a Certified Scrum Master class and is giving away some goodies to DFW Scrummers!

Peter loves giving away free stuff. He will be giving away:
- Copies of his book The Agile Pocket Guide –
- Apple Gift Cards!
- One lucky winner gets a free pass to his next public Certified ScrumMaster Course in Dallas – A $1300 value!

You can find Peter Saddington in Dallas every other month doing public courses in Dallas. His next courses are October 10/11 and December 5/6 –

EXTRAS for Dallas Scrum Participants:
- All participants in the Dallas Scrum Meetup can get a 40% discount on Dallas Certified ScrumMaster Courses! Type in the code “dallascsm001″ in the coupon code field –

Wondering who is this generous guy?

PETER SADDINGTON owns a successful research and analytics consultancy and has been integral in multi-million dollar Agile Transformation projects with some of the biggest Fortune 500 companies, including Cisco, T-Mobile, Capital One, Blue Cross Blue Shield, Aetna, Primedia, and Cbeyond. He is a sought-after speaker at many industry events and is a Certified Scrum Trainer (CST). He has also received three master’s degrees, one of which is in counseling, and provides life-coaching services in addition to his consultancy.

Strategies for Agile Portfolio Management with Kenny Rubin

Kenny Rubin

Kenny Rubin

For our June meeting Kenny Rubin, a Certified Scrum Trainer through the Scrum Alliance and author of Essential Scrum, was kind enough to speak to our group via webex about portfolio management.  To answer the question of “why is portfolio management important to a scrum user group?” I found this quote from an interview with Kenny:

Many of the problems in organizations start at the highest levels of planning—such as portfolio-level planning. When these higher levels of planning are poorly aligned with agile principles, you can be certain that the misalignment will manifest itself in an ever-increasing snowball of problems that roll downhill toward the development teams. For example, working on way too many products/projects at one time is a classic problem at the portfolio level, experienced by pretty much every company I see. People at the team level are pulled in so many different directions that they have a hard time staying focused and getting the job done. The concept of managing work in process (WIP) applies as much at the portfolio level as it does at the team level, and I wanted to make this alignment clear.

Kenny reviewed 11 portfolio planning strategies that he organized into 3 categories: scheduling, inflows and outflows.  While a company doesn’t necessarily need to use all 11 strategies and there are probably more that he didn’t call out explicitly, more than one must be used in order to be effective.  For more information on the strategies, review Kenny’s presentation at  He will also be presenting this topic at the Agile 2013 conference in Nashville, and I look forward to meeting Kenny in person there.