Daily Stand-Up Meetings for Distributed Teams

Distributed Agile teams require a different level of care than a co-located team in order to ensure that they are as effective as possible. This is even more true for a team that is working through their forming-storming-norming process. Core Agile concepts are the team and communication, and these are key for the success of distributed Agile teams. Daily stand-up meetings are one of the most important communication tools for teams using scrum or other Agile/Lean frameworks, so it’s important that they function properly.

Here are some tips for making daily stand-ups work for distributed teams:

  1. Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint, so that everyone loses a similar amount of sleep (share the pain). One solution for when distributed teams can’t overlap is to have one team member (rotate) stay late or come in early to overlap work times.
  2. Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties do not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered, so that something discovered late in the day in one time zone does not affect the team in a different time zone (where they might just be starting to work). One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  3. Push status outside of the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI or similar shared document for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  4. Vary the question set being asked. The process of varying the question set for each meeting keeps the team focused on communication rather than giving a memorized speech. For example, ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get competed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams as well.

  1. Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  2. Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion must include the willingness to ask for help and to provide help to team members.
  3. Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table, so that the focus can be on communication. Use of a physical wall in a distributed environment means using video to show the act of someone on the team physically moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that everyone has access to. Keep tools as simple as possible.
  4. Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event; not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they cannot communicate.

Stand-ups are nearly ubiquitous in Agile. However, despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.

Tom Cagley
VP of Consulting & Agile Practice Lead



Written by Tom Cagley at 05:00
Categories :

What Does An Agile Coach Deliver?

Tom CagleyI am an Agile Coach, and I'm often asked about the role that Agile Coaches play in an organization. On the most basic level, Agile Coaches help teams and organizations embrace Agile and help maximize the delivery of business value from development. We use terms like "enable" and "facilitate" to describe how we help organizations and teams transform. But what does an Agile Coach actually do? Well, it's a variable mix of activities that includes: consulting, cajoling, training, arbitration, and mentoring.


Coaches sometimes act as consultants. A consultant will actively involve him or herself in the game. Sometimes an Agile Coach will have to actively participate in performing a task or activity so that the team can see the technique in action.


Coaches cajole, with gentle urging or coaxing, the team or organization to change behaviors that don’t live up to Agile principles and values. In many cases, this cajoling is underscored by the war stories a Coach can deliver about the trials and tribulations that will ensue if certain behaviors are not corrected. The experiential base is important for the Coach to be able to hold the moral (metaphorically speaking) high ground needed to persuade the team or organization.


Coaches deliver training. Training comes in many shapes and sizes. Coaches will be able to deliver training on a just-in-time or ad-hoc basis based on their own observations of how work is being done.  The goal of ad-hoc training is to ensure that the team or teams understand how to apply specific techniques as they are applying them. I liken this to a form of just-in-time training, which leverages a principle from adult learning that holds that adults retain knowledge better when it can be immediately applied. This does not exclude leading and organizing training as part of the more formal organizational change program.


Coaches arbitrate conflicts and difficult decisions. Projects, whether to transform whole organizations or to implement a set of simple user reports, always include the need to make decisions. Coaches help organizations make decisions so that they can move forward with a minimal loss of inertia. Facilitation for an Agile organization is a skill that is part art and part science – think emotive negotiation (or as a friend of mine calls it “family counseling for teams”).  The best Coaches teach the team or organizations they are working with these skills.


Coaches mentor. A mentor is a trusted counselor who provides guidance, advice, and training, usually at an intimate (one-on-one) level. A mentor needs to be dependable, engaged, authentic, and tuned into the needs of the mentee, so that the transfer of guidance is safe and efficient.

So, when we say that an Agile Coach enables and facilitates, what that really means is that they  consult, cajole, train, arbitrate, and mentor. The art of being a good Coach is knowing what mix of these activities is appropriate for any specific situation. And, as many readers probably are aware, a good Agile Coach can make or break an Agile transformation.

Tom Cagley
VP of Consulting & Agile Practice Lead

Written by Tom Cagley at 05:00
Categories :

Test Maturity Model integration (TMMi): Definition and History

Tom Cagley“All models are wrong, but some are useful.” – George E. P. Box

Testing is a mechanism for affecting product quality. The definition is of quality is varied, ranging from precise (Crosby – “Conformance to requirements”) to meta-physical (Juran – “Quality is an attitude or state of mind”). Without a standard model of testing that codifies a definition, it is difficult to determine whether testing is affecting quality in a positive manner. The Test Maturity Model integration (TMMi®) is an independent test maturity model. A model provides a framework of the activities and processes that need to be addressed, rather than merely laying out a set of milestones or events that need to be followed explicitly.

The TMMi is a reference model representing an abstract framework of interlinked concepts based on expert opinions. The Wikipedia definition suggests that a reference model can be used as a communication vehicle for ideas and concepts among the members of the model’s community. The use of a model as a tool to define the boundaries of a community also amplifies its usefulness as a communication tool, as it defines the language the community uses to describe itself. Thus, the TMMi is a testing reference model, for the testing community, defining the boundaries of testing, the language of testing and a path for process improvement and assessment.

Many developers (and development managers) think of testing as a group of activities that occur at the end of coding. This flies in the face of software engineering practices that have been in use since the 1980s and the Agile tenant of integrating testing into the entire development process. The TMMi model explicitly details a framework in which testing is not an event or gate that has to be hurdled, but rather a set of activities that stretch across the development lifecycle (waterfall, iterative or Agile). The TMMi model extends the boundary of testing to the entire development process.

The model lays out a set five maturity levels and sixteen process areas, ranging from test environment to defect prevention. The model has a similar feel to the classic CMMI model. The TMMi, through its framework of maturity levels, process areas, practices and sub-practices, lays out best practices for testing that should be considered when developing testing practices. Like other reference models, the TMMi provides a framework but does not prescribe how any project or organization should do any of the practices or sub-practices. By not prescribing how practices are to be implemented, the TMMi can be used in any organization that includes testing. A framework that is neutral to lean, Agile or waterfall practices is a tool that can be molded by managers and practitioners to make testing more efficient and effective in almost any organization.

DCG is a TMMi Accredited Supplier, which means that we can walk you through the model and address all of your questions and concerns, as well as assist with TMMi assessments and appraisals. If you're interested in learning more about how the TMMi works, read this case study on how DCG helped one organization to apply the TMMi and improve its testing processes.

Tom Cagley
VP of Consulting, TMMi Accredited Assessor

Written by Tom Cagley at 05:00

Scaling Agile Testing Using the TMMi

Tom Cagley 2014Agile methods, principles and techniques are core to how many IT organizations develop and maintain software. However, even though techniques like Test-Driven Development and scrum are widely practiced, one common complaint is that it is difficult to scale these practices. In large projects and programs, this is code for “testing gets squeezed as though it were 1999."

Scaling Agile, in general, and Agile testing, specifically, requires having a framework to help teams, stakeholders and program managers to identify what is needed to deliver quality and value. 

The Test Maturity Model integration (TMMi) is a framework for effective testing in an Agile environment. The TMMi is not prescriptive; rather, the model is outcome-focused. Using such a framework to scale helps teams and organizations to make decisions that ensure that testing is not only cost efficient but also effective. 

If you think that this framework would be useful for your organization, join me for a webinar on February 19 to learn more.

The webinar will outline the TMMi and provide a process for using environmental, technical and project context to effectively integrate testing into an Agile development environment, measuring the effectiveness of the process.

Register Now!

Tom Cagley
VP of Consulting, Certified Scrum Master, TMMi Accredited Assessor

Written by Tom Cagley at 05:00
Categories :

Tom Cagley Reflects on DCG’s 20th Anniversary

DCG 1994 Logo 2C

This is the fourth post in a series that will offer our management team's reflections on DCG's 20th anniversary and the state of the software industry. Previous posts herehere and here.

 In the world of software development, software enhancement and software maintenance, only one adage has remained true for the past twenty years. Simply put, “If you are currently doing work the same way you were last year, you are out of date.” Processes, techniques, methods and even languages are in a continuous state of change. In order for anyone involved in this industry to stay relevant, they need to continually learn, adapt and adopt the new techniques that deliver value (and not all of them do).

 Of course, change in software development is not as simple as flipping over an etch-a-sketch, shaking and starting again. Each successive wave of change, regardless of the speed at which it happens, leaves at least a little of its essence behind for the next wave to build upon. Examples abound; consider the pedigree of the lean/Agile movement, which can be traced to the design pattern movement in the 90’s, to the continuous process improvement and quality movements of the 80’s, to the works of Dr. Deming and beyond. Just as volcanos build islands, waves of change within software development build on each other. 

 In addition to “change as a constant,” a few other core software principles have not changed: 

  • Software development is an important enabler for most organizations. Software is everywhere, used in almost every job imaginable. Even my local garbage collector uses software automation on its trucks.
  • Software development needs to be managed as a profit or cost center. Pick one, although unless you are selling your software, it will tend to be the latter. Regardless of which you choose, the impact on the corporate bottom line requires IT (in general) and software development (specifically) to be managed as a business.
  • Software development is a mixture of engineering and art. The culture war between the engineering camp and the craftsperson camp has not totally died out; however, mature software development organizations have found a way to merge both points of view. Frameworks such as Agile are a reflection of the two camps blending together . . . albeit noisily.
  • Software development can and should be measured. Whether you use IFPUG or COSMIC function points, SNAP (non-functional size) or you count stories, the techniques that exist to measure productivity, velocity and delivery rate should be used. The questions of “When can I have that project?,” “How much will it cost?” and/or “What will I get?” are not going away. Whether you are a parametric estimator or you adhere to the #NoEstimates thought processes, you need to measure something.
  • Software development is a people business. The raw material of software development (at least currently) is human thought. Without IT professionals and end users that feel they are appreciated and belong, very little good software is delivered.

 So, what will software development be like in 20 years? Will these trends persist? Humans are notoriously poor predictors of the future. What can be said with certainty about how we develop, enhance and support software-centric projects is that the way we work today will not be how we work tomorrow. Will techniques like Agile or architectures like cloud be more prominent? They will likely run through a lifecycle to be replaced by a new tool, a new process or a new architecture that will build on the changes delivered. Software does not stay stagnant.

 Where will DCG be in twenty years? The answer is probably very similar to where software development will be. One general observation I can make, as someone that came to DCG from the outside (corporate and consulting) in the relatively recent past, is that everyone at DCG is a voracious learner and has a passion to be involved in the industry. One of the reasons I joined DCG was to be pushed and that has happened. Therefore, if I were to predict the future, I would say that in twenty years we at DCG will be discussing where software development will be in 2054. That said, has anyone seen my COBOL manual and coding sheet?

Tom Cagley
VP of Consulting & Agile Practice Lead

Written by Tom Cagley at 05:00
Categories :

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!