Setting and Achieving Goals as a Change Agent



I. Goal Achievement and Organization

  • These go hand in hand. There is much that can be said about goal orientation. It has to do with attitude. The attitude of the leaders to the goals and their potential problem and the followers and their attitudes. We need to be concerned as to whether our teams are “problem-centered,” or “objective-centered.”
  • Keep your eye on the doughnut, not the hole.
  • Of course we know that problems will arise, but we need to remain focused on the goal.

How can you tell if your team is goal-oriented or problem-oriented?

Questions to consider …

  • Are we generating new ideas to accomplish goals and objectives?
  • What has caused any changes?
  • Do we have room for the “out of step” leader … those with different ideas?
  • How do we utilize business session times? What happens in our church meetings? How much time do we discuss goals vs. problems?

How can a problem-centered company be “turned around?”

4 ways to develop objective-orientation

  1. Reorganize the decision-making process – decisions should be made at all levels of authority – decentralization
  2. Eliminate timidity – people must be willing to speak up
  3. Decentralized systems input – decentralizing the kind of information that is necessary to operate a company or organization – people in the organization then will know what is going on from the top and they are able to have input as to what happens at the top – employees are able to speak to the powers-that-be and share concerns and ideas
  4. Reduce long lead times – setting goals with sub-objectives – It is tough to keep people motivated by a long-range goal if they do not see anything intermediate (smaller achievement levels need to be built in) – Iterative development!

Goal Orientation

5 Aspects of the Importance of Goals and Objectives

  1. Objectives must be derived from what our company vision is, what it will be, and what it should be
  2. Objectives must be operational, capable of conversion into specific targets and assignments
  3. Objectives must make possible the concentration of resources and efforts – you nail up a specific target/goal so that everyone can focus on it
  4. Objectives must be multiple, never singular. We have many objectives.
  5. Objectives must relate to all areas of which the progress of the company depend


10 Common Time Wasters

  1. lack of planning – leads to crisis management
  2. crisis management – running from here to there, no plan for approaching the issue
  3. lack of prioritizing
  4. over commitment
  5. undo haste – rushing to do stuff – we are never really efficient in the heat of the moment
  6. paperwork (busy work) and reading (not all) – in the office only read that which is directly related to your goal achievement
  7. interruptions
  8. meetings
  9. indecision
  10. failure to delegate

The Seven Major Time-Wasters

  1. Telephone interruptions
  2. Unexpected visitors (drop-ins)
  3. Meetings (planned and extemporaneous)
  4. Fire-fighting (unexpected crises)
  5. Procrastination
  6. Socializing
  7. Indecision

Keys to Effective Time Management

  1. Make a firm decision to become excellent at time management
  2. Set clear goals and objectives that are consistent with your highest aspirations
  3. Create detailed plans of action and get organized for productive work
  4. Establish clear priorities and always work on your highest value tasks
  5. Develop good work habits and learn to concentrate on one task at a time (the most important task)
  6. Think through and carefully plan large jobs or complex tasks that involve several people

According to time management specialist, Michael Fortino, over the average lifetime people spend …

  • 7 years in the bath room
  • 6 years eating
  • 5 years waiting in lines
  • 4 years cleaning house
  • 3 years in meetings
  • 1 year searching for lost items
  • 8 months opening junk mail
  • 6 months sitting at red lights
  • 120 hours brushing your teeth
  • 4 minutes per day talking with your spouse – as it averages out
  • 30 seconds per day talking to you kids – as it averages out

We, therefore, must learn to save time …

We must continually ask…

  • “Why am I on the payroll?”
  • “What have been called to accomplish?”
  • “What am I supposed to do?”
  • “What results have I been called to achieve?”
  • “Is what I am doing right now contributing to the accomplishment of my most important goals, objectives, and responsibilities?”

These are some ideas on what is going on… now, what do we do about it? Time to focus. Do great work. I would/could say… that FOCUS… or the ability to focus is the key in a lot of ways. What other things would you add to my thoughts here?

The Best Training Isn’t What You Say, It’s What You Do

Dear Peter Saddington,

Thank you for the two day course for Scrum Masters.

I really liked the way you helped us learn Agile and Scrum through team activities.   Your training method itself reflected the principle that doing is more important than reading theory.

And you overcame so many obstacles (no projector / bad TV / faded markers / locked doors / late comers / fire drill) to enable us to focus on the session.  You showed us the qualities of a true Scrum Master.

Thank you also for sharing anecdotes from your personal experiences.  Your career path and academic qualifications inspire many of us.

I have been a huge fan of Agile principles, and I long to be part of a true Agile team.  You helped me picture the ideals with so much clarity that I truly hope my aspiration to be in an agile organization will come true soon.

Thank you.


Making the World Round Again with Agile

scrum-cycle-peter-saddingtonOnce upon a time, the world of software development was flat. The customer had a product to be developed, which they handed off to a vendor, who handed it off to workers. In this linear process, odd schedules and isolated teams were the norm, and any true collaboration was limited to a few hours a day at best. The bible of instruction was a Requirements Document that stayed the same even as months passed and the software evolved in unforeseen ways. The unfortunate byproduct of this arrangement was a distance in time, geography and understanding – and the final product often suffered as a result.

Then agile came along, shook things up and gave outsourcing what it needed – a way to make the world round again. With agile, development is collaborative and flexible, rising from a foundation of frequent interaction and fast-paced response cycles. Instead of relying on an up-front set of instructions and working through testing and revision cycles at the end, teams work with customers throughout the cycle to optimize the design in real time. The result of this streamlined model: an accelerated road to market with a product that’s perfect the first time.

Consider this example:

Let’s say an online shopper needs to enter a credit card number to place an order. In our flat world model, that’s all we would know – we wouldn’t know what the screen should look like or what other data should be collected. The odds are high that we’d turn in a product very different from what the customer envisioned, and have to make expensive corrections. But in our round world model, we’d start with a well-rounded user story that would help us flesh out a more accurate, satisfying product. We’d also repeatedly meet with customer to collect their feedback and refine the product based on their ideas. The end result would be software that matched the customer’s vision.

So just how do you make this new world happen? Collaboration is key – that much is clear. However, it’s also important to know that this round world doesn’t just happen laterally, but longitudinally. Read on for the best practices that can turn your software development world round again.

Tactical Execution – Lateral Agile


Like we said above, in the flat world of waterfall development, customers hand the Requirements Document over the fence to the provider as a static directive that lays out a problem to be solved – and the two businesses don’t intersect again until the vendor hands back complete, working software. As you might guess, that leaves more than a little room for guesswork and assumptions. Agile, however, relies on frequent communication and multiple interactions per day to keep the project on course. The teams clarify what will be built, answer questions and request feedback. We synchronize the communication rhythm and ensure that all team members have tools like Skype to enable immediate conferencing.

The difference is colossal. Imagine building a house in the United States; normally the owner would provide regular feedback on the flooring, shower tiles or cabinet finish so the builder could rectify mistakes on the spot. But if the owner only saw the house once it was complete, correcting all of the wrong features would be a massive and costly endeavor. This is the exact fate good agile communication prevents.


Even when you’re working on a project within your own company, smooth collaboration can be a challenge. When a project involves a customer, a vendor and an outsourced team, the potential for communication breakdowns and lost opportunities are even greater. For this reason, smart customers and vendors recognize the wisdom of using workers who are close by. Using an Indian team might make the most sense for a company in that time zone, while using a Mexican team could be the best choice for an American business. The physical proximity can lead to more efficient supply chains, faster delivery times and easier meeting access, something not to be overlooked.


Agile is all about staying attuned to user stories and customer needs, so we can build the most relevant, useful product possible. And the way we do that is through meetings. Daily huddles help us identify potential problems, reduce email, eliminate roadblocks, and incorporate customer feedback. Instead of disconnecting from the customer during development, we invite them to experience the software features in progress and provide feedback for corrections and enhancements. Not only does this lead to greater customer satisfaction, it saves time and money correcting errors post-production.

Strategic Choices – Longitudinal Agile

Cultural compatibility.

While outsourcing models involving offshore teams may work for some projects, agile teams benefit far more from using teams in culturally relevant locations. Near-shoring has become a popular model for agile development for many reasons; it offers the considerable cost savings of outsourcing while eliminating time zone difficulties and language barriers. Instead the team works with developers that live in complementary time zones and share a similar culture. The result is deeper engagement, tighter collaboration and increased profitability.

Shared agile understanding.

To design the best possible software, all players on an agile project should ideally operate as one team – and this is best accomplished by utilizing a shared framework that defines roles, processes and systems. All teams should observe the same daily, weekly, monthly and quarterly operational rhythm, as well as a common vocabulary; when you consider the potential for different definitions between team members or with customers, the need for precision become clear.  Taking the time to clarify coding terms or testing stages can eliminate misunderstandings and enhances communication, ensuring that the teams grasp the customer’s expectations.

There’s no doubt that agile has simplified and accelerated the world of software development. By adopting agile methodologies, teams can reconnect with their customers and each other for cost savings, faster time-to-market and greater productivity. And by weaving communication and collaboration into every step of the project cycle, agile teams can offer their customers the most accurate and perfect product possible.

[Cliff Schertz is the founder and CEO of Tiempo Development, which provides cloud-focused companies with a powerful, integrated platform of services know as Tiempo Quality System™ (TQS)that transforms the way their products are developed, deployed and supported. For more than 25 years, Mr. Schertz has been leading and growing successful technology service companies, enabling his customers to achieve superior performance, high customer satisfaction and profitability.]

Agile Coach Leadership Traits


What is Leadership? 

Three Styles

  1. Autocratic – Has to do with a totalitarian approach to leadership. This is more of an attitude than a leadership style.  This leader demands instant obedience, no discussions from underlings are desired. This is NOT a desirable leadership approach.
  2. Free-rein – The opposite of autocratic. This is more of a “hands off” approach. This is a good approach when dealing with highly skilled and expert individuals (professionals). Some of the more “blue collar” type individuals actually do not desire a free rein approach. They are told what to do and when to do it at work, they almost expect similar treatment at church.
  3. Participatory – Typically the best approach. Group decision-making, multiple leadership. There is, however, a leader at the head.

 Three Components

  1. PersonThe particular personality traits and leadership attributes the leader brings to the table. There are different personality types and individuals will respond differently and accordingly to this personality depending upon his or her personality.
  2. Group – The question is: “What kind of leader does this group actually need?” AM I WHERE I NEED TO BE?
  3. Situation – Leadership is situational. We can take the same leader who was successful in one scenario and place him or her in another scenario and NOT have the same exact results. Happenings may be slower, faster, not at all. Rather than success, failure could be more commonplace.  This could be related to any number of factors: geographical, cultural, social issues, political differences, phraseology, management approaches, leadership styles, etc.

Three Terms

  1. Leader – Really comes down to what a person is. He or she IS a leader. Generally a leader is one who has the ability to influence individuals to follow a particular direction or pursue a particular goal. John Maxwell, “Leadership is influence, nothing more, nothing less.” Leaders are goal-oriented.
  2. Administrator – These are more result-oriented. They strive for order, to correct failures, and operate systems.
  3. Manager – same as administrator.

Leaders inspire people, but managers depend on systems. Managers attempt to adjust to change, while leaders attempt to produce it.

Leadership Check Up Continue reading “Agile Coach Leadership Traits”

Becoming an Agile Coach – Effective Communication Techniques


Effective Communication Techniques 

Communication requires cultivation of techniques. It is not something that comes naturally. The number one reason relationships fail is poor communication (leads to massive misunderstanding).

Five Conditions to meet for effective communication:

  1. Desire – you must want to be effective. It really must be a consuming passion. Love for coaching and teaching should drive you to desire excellence.
  1. Understand the process of communication – the three aspects of communication MUST be understood and appreciated. We use words, but we also use imagery and gestures. We also receive data back from listeners. What seems so easy is really a very trying art and science. But this can become quite easy once we appreciate the process of communication. We are dealing with needs, emotions, feelings, and realities. These are serious issues and we must take them seriously.
  1. Master the basics – three basic skills
    • Connecting with the listeners
    • Conveying information in ways they can understand it
    • Checking responses (interest levels and connectivity is seen in body language)
  1. Dedication to Practice – It’s time tested. Which means you won’t be a rockstar on day one.
  1. Patience and Persistence – time is our friend. We will get better. There is simply no way it cannot happen if we follow the first four conditions. Self-evaluation is of tantamount importance.

How do I get people to pay attention to me?

We all want attention. We thrive on it and want more of it.  It is human nature, but it is also an enemy of the Agile communicator. Why? Because we want to draw people’s attention, not to us, but to the potentially life-changing affects of being agile…

The first law of communication is audience attention. You must get their attention.

Three techniques for getting and keeping attention:

  1. Pay attention to others and they will pay attention to you. Work the crowd. Don’t simply appear. We must be the right person, at the right place, at the right time. We speak truthfully to needs, fears, hurts, and on practical and relational matters. In the speaking event, the listeners are our top priority, not us or even our message..
  1. Overcome the stiff competition for attention. People are no longer getting the personal touches they desperately need. We are closer physically than ever before, but fail to connect with most people. Ever notice the service attendant at the drive-through window? Ever notice how people will not acknowledge each other in elevators? People tune out or “filter” people out of our lives or environments. This makes communication very difficult.
  1. Be interesting! Build messages in creative ways! Push yourself beyond your self-created limitations. People come to speaking events prepared to “turn on the filters.”

5 tactics to improve communication Continue reading “Becoming an Agile Coach – Effective Communication Techniques”

Ideas on Managing Distributed Teams Using Agile [3/3] – Review and Conclusion


Things to be followed by Distributed team in Sprint review meeting:

  • Keeping Track of the Stakeholder Comments -During the sprint meeting, the distributed team needs to capture these comments so the Product Owner and the development team can decide which ones they will act on.
  • Effects of Distance – The facilitator of a distributed retrospective needs to understand the cultural differences in the team. SM needs to understand how different cultures interact when they want to change something
  • Or have issues they want to talk about that can help the facilitator encourage participation from all team members.
  • Release Planning –The number of Sprints to map out and use with “Look ahead Planning Technique” will depend on Sprint length, dependencies, and needs of the teams involved.
  • Engaging Stakeholders – At enterprise level environments, to address the diversity of data by the Scrum team, the PO can help identify which customers are representative of different markets.
  • Resolving Blockers – The SM should create a list of blockers and assign them to team members or managers. The SM should also ensure the team is burning through the blocker list.
  • Handling New Requests in the Middle of a Sprint – In Distributed Scrum, it becomes mandatory that the team commits to sending requests through the Product Owner(s), who will decide the priority of the request in the Product Backlog.
  • Demos May Provide a False Sense of Completion – Add a DRAFT watermark on any screenshots or to use data that is clearly not real, to avoid false sense of completion to the stakeholders. Setting Expectations – The facilitator, for distributed teams, should talk to the team ahead of the first retrospective and explain the expectations for the retrospective.
  • Remote Demonstrations – Network Delays and Poor Performance – Distributed Team should test their tools ahead of time to be sure the distributed meeting will run smoothly, without network poor performance

The team can also consider making the recordings available for download before the demonstration meeting and discussing them through a teleconference.

Understanding the Team Members’ Personalities

Team have a different combination of personalities, and the facilitator of the retrospective needs to understand the personalities of team members to lead the meeting effectively.

  • Teleconference Meeting – Distributed teams with overlapping work hours should use a teleconference call to the same phone number every day to hold their Daily Scrum meetings.
  • Videoconference Meeting – The main advantage of this approach is that team members get to see one another, so there is less nonverbal communication loss. Dealing with Defects – Distributed team may want to consider creating a user story with a certain number of story points in the Sprint to deal with the problems, OR, they can set a priority for the maintenance tasks as per the customer log OR create a subteam to focus only on handling these issues during the Sprint OR depending on the skill set of the technical support team team to make the necessary code changes
  • Services May Vary by Location – Set up a single machine with a standard configuration that everyone uses during the demonstration meeting. Before the start of the meeting, distributed team members can access the machine (remotely or locally) to bookmark links, set up scripts, and do a quick dry run of their presentation.
  • Respecting Cultural Differences – SM needs to make sure cultural difference should not be taken lightly during the retrospective meeting in distributed teams
  • Managing Dependencies within the teams – Agile teams will not try to account for every possible dependency at the start of the project, but will look ahead two or three Sprints to ensure that teams are ready to deal with dependencies, using INVEST model
  • Gaining Commitment – With a distributed team,team members who are sensing that other team members have unspoken issues need to take responsibility for drawing attention to the issues to SM because of this, the SM needs to rely on the whole team to take responsibility for ensuring good communication.

Approaches to Handling Time Zone Issues

Distributed Teams can use four different methods to deal with distributed Daily Scrums where the team has members with no overlap in their work hours, as follows:

  • Daily Scrums through documentation
  • Liaison approach
  • Alternating meeting times
  • Share the pain Disruptions at the Team Member Level – Handling Stories the Team Cannot Complete During the Sprint – Before working toward the solution, the team first needs to identify the work they need to do to complete the story through meetings between team members or with the Product Owner.
  • Asking for Comments Before the Retrospective Meeting – What Went Well and What Can We Improve?
  • Ask the team for comments about issues or problems they noticed since the previous
  • Sprint retrospective and summarize them for team discussion. The result is still an action plan and a list of behaviors the team needs to change or continue in the period until the next Retrospective.


During the Release Plan, the PO will want to identify the risks associated with the project and teams, when possible, the mitigation plan for each of them Note: No one should interpret silence as agreement. Team members should phrase questions in a way that needs a verbal response to improve the understanding within the team. Precautions to be taken while conducting Distributed Scrum meeting

  • Increased distraction – Background noise can be distracting on a teleconference so teams should chose a room to conduct the meeting.
  • Handling Blockers During the Sprint – In the large scale enterprise transitioning to agile, the SM needs to hear from Distributed Scrum Team members who are facing blockers and dealing directly with inhibitors will help increase the velocity of the team over time, as well as the velocity of other teams as they transition to Scrum.
  • Provide Questions to Focus the Discussion – In distributed setup, team members respond to a set of questions developed or selected by the team. The purpose is to focus on a few issues and address them effectively instead of trying to address a lot of issues and address them poorly.
  • Coordinate Multiple Product Owners of different teams – Product Owners meet regularly to discuss Product Backlogs, dependencies, and links between and boundaries between user stories w.r.t. different teams
  • Release Plan Check or Update: Enterprise Scrum Teams often begin providing tasks for high-priority user stories before the Sprint Planning meeting. All team members discuss the tasks because it helps with communication for distributed and scaled teams and provides opportunities to find better ways of completing the user stories. Silence on a teleconference is not a commitment.
  • Keeping the Team Engaged – Possibly the best way to stay engaged and to make sure that others on the team stay engaged is: Awareness. Build awareness of what the team is working on.
  • Advertising. Advertise for collaboration.
  • Attack blockers. The team and SM should strive to fix all blockers within one hour of the Daily Scrum
  • Responding to Questions During the Sprint – For enterprise product development, the PO should look for ways to match representative stakeholders with the teams’ working hours and to be available during that time as well. For applications the team is developing for a specific client, the Product Owner may not have the flexibility to choose stakeholder representatives available during the full working day of the client.
  • Discussing Reported Issues – During their retrospective, the team reviews the reported issues and, if others feel strongly enough, the team addresses them, creates their action plans, and log them as actions they will revisit in follow-on Sprint retrospectives to evaluate their success.
  • Facilitating the Meeting – In a distributed environment, as individuals come into the call, they will identify who they are. The SM calls each person and asks for their response. They may respond in the order they arrived at the teleconference or the SM may choose to call on each person
  • Sharing Time Zone Challenges – One approach to help manage such cases is to make sure that distributed teams in different time zones are fully self-sufficient and the team spreads the work to minimize dependencies.
  • Managing Time Effectively – Limit the discussions to a limited set of issues, it is important for the team to agree, this is the right set to be talking about in the meeting. The meeting facilitator may want to keep a window of time open for unplanned issues that come up during the retrospective.
  • Invest in Smarter Development – Test automation and continuous integration help agile teams to complete user stories within a Sprint, working together or for distributed teams.
  • Taking Daily Scrum Notes – Helps the distributed team members to overcome language problems, plan and learn. Chat Tools & Wiki help distributed teams to do Daily scrums.
  • Continuous Integration – Continuous integration is the key to delivering stable, high-quality code consistently and quickly, which results in reducing time to market for any distributed agile team Release Retrospectives – The team talks about the project, and then defines and records the milestones in the project like initial training, team formation, Stand -up Meetings, start of development, middle of release, deployment etc.

Coordinating Agile and Non-Agile Teams

Making sure the non-agile team is aware of the priorities of the agile teams and keeping dependencies visible can help to prevent blockers between the teams. Scrum of Scrum can solve distributed team road blocks, future dependencies, commitments to other team members, issues with integration, and other points that impact one another.

  • Reports Any Build Failures to the Team – Allows the Distributed team to know the current state of the code in the integration branch of the source control system, generating a notification email for build success or failure.
  • Face to Face Collaboration –SM should reduce the amount time spent each day on project setup tasks, which will extend the duration of the project startup tasks and enables to build trust and relationships needed in distributed development efforts.
  • Reduces the Risk of Integrating Code – Continuous integration ensures a build runs regularly and allows the distributed team to identify integration issues earlier when they are less costly to fix. This practice helped the team to identify design problems and avoid introducing defects in scenarios we did not cover. These smaller testable deliverables allow the team members testing the feature to start their work in parallel with the development.
  • Establishes Greater Confidence in the Product – When developers are doing the unit testing of their code, they should also create automated unit tests as continuous integration certifies every build, developers can make changes with more confidence and the entire team can remain in sync with the latest build.
  • Reduces the Time to Find Integration Issues – Developers receive the build status by email, so they can see and fix problems. The next time the build runs, the build status changes from fail to pass automatically.
  • Improves the Efficiency of the Team – Distributed Teams efficiency can be improved by automating once and then reusing as much as possible. This removes human error, provides consistency, and frees up people to do higher-value work.
  • Builds Can Run at Different Frequencies – Setting up the hourly build helps the distributed team to know about a failure closer to the time of the code integration, and team members can take action on it earlier.
  • Test Automation – To streamline the testing and help the distributed team to get as much done as possible within a two week Sprint, teams should automate time-consuming manual processes where possible
  • Dedicated Automation Teams- The developers in distributed teams should tell what is ready to be automated to allow testers to closely couple with the product. And other testers in the distributed team doing manual executions and informs their highest-priority items for automation as well.
  • Identify High-Value Automated Tests – Testing installation and configuration of the operating system, regression tests, as well as acceptance into testing tests all have a high rate of return because the distributed should often repeat and in different environments.
  • Automate What Is Stable – Automated test cases should be created for parts of the project that are stable will help teams improve their effectiveness and avoid rework.
  • Test-Driven Development – For distributed teams, if someone is working on code written by a developer in another geographical location, having the built-in documentation in the code helps reduce their dependency on the author and enables them to work with the code faster. Working directly with the source code provides a common language for the developers and removes languages barriers.
  • Helps Reduce the Time to Fix Defects – By using such tests and fixing the area where the problem is occurring, the developer in distributed teams can save the time needed to create a full build, start the application, get to the right place, and test the fix manually.
  • Helps Improve Code Quality and Provides a Safety Net for Changes – As the distributed team should write the unit tests first, providing test coverage for all or most of the code, thus, provides an early defect detection process where developers can improve the code knowing the existing set of tests will detect any problems.


Distributed team needs to go for mandatory training to run into full fledge agile teams so that they could understand the potential impact of making the change. Although the project teams are undergoing through while adjusting to be a distributed agile teams, it becomes more important for them to understand and adhere to Scrum, rather than immediately thinking that Scrum needs to be changed.

I believe that collaboration becomes very important in distributed teams as they collectively responsible for delivering on their commitments. One important key to having success in managing distributed team is to have a high commitment level from all team members, and the best way to get that is to give them ownership over how they will work.

Another key to embrace self-managed distributed team is valuing the entire team and not having an “us versus them” atmosphere between different Scrum Teams on the project. The best ways to build relationship within teams is to find ways to share the pain of being a distributed team, to get to know each other as people, and to foster frequent, quality communications between team members.

Another way to introspect the distributed team management is to use their Sprint Retrospectives to see what they are doing and how they are communicating is working for them; when they need to adjust, they should do so as fast as possible.

I must say the teams with members distributed across sites can enhance code ownership and improve autonomy essential to team self-organization. Automated communication of Product and Sprint backlogs throughout the organization combined with upward reporting of teams’ status to management can tightly align the team distributed teams together.

Ideas on Managing Distributed Teams Using Agile [2/3] – The Retrospective


Retrospective Timings :

To be effective and timely, distributed teams should call joint retrospectives as soon as possible after having their own team meeting. Depending on the no. of teams involved in a joint retrospective, teams may want to limit the number of participants from each Scrum Team to keep the meeting productive.

  • Team Composition – Teams >=9 people should consider geographic closeness and proper distribution of skills as well as team size so as to build self-organizing teams
  • First level of Sprint Planning – The PO, SM will use a screen-sharing tool to display the vision, sprint goal, user story, the estimates the team provided, and the acceptance conditions for the user story.
  • Answering the 3 questions: Team members should communicate information that brings value to others on the team. They should also try to identify team members that can help them resolve their issues.
  • Documentation helps to Overcome Distance: Because of language barriers, distributed teams often need more written documentation than collocated teams. Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting or to have a fluent speaker speak over the recorded demonstration.
  • Hold Joint Retrospective – The Distributed Teams working together will conduct their individual
  • Sprint retrospectives at the end of each Sprint and then will conduct a joint retrospective.
  • The benefit of this approach is that it promotes communication between the various teams involved in a project
  • Individual Scrum Teams should aim to have the lowest distribution level possible encouraging feature teams over component teams.

Dealing with Incomplete Stories

The PO takes the impact of dependencies into consideration when reprioritizing the Product Backlog due to work the team did not complete during the Sprint, highlighted in Scrum of scrum Coordinating the Team on a Daily Basis – Priorities can change daily. The Daily Scrum meeting provides a daily synchronization point for the team and allows them to revise their plans regularly. Using the Right Tools : In a distributed environment, tools and good practices can help team members communicate more effectively, but it is more important to make sure the tools the team introduces will help them get the job done.

Scheduling for Teams with Overlapping Work Hours – Make sure all team members of distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.

Larger Retrospectives

Distributed team members can reflect and comment on release quality and capability. The team talks about the project, and then defines and records the various milestones within the project to improve on or continue in future releases.
Enterprise planning tools for distributed team members, PO & SM to develop more than one feature to address a single solution so as to disaggregate the higher-priority features into user stories that can fit within a Sprint.

Checking Estimates from Preplanning Teams

In scaled environments where teams send representatives to help with preplanning, it is important
the teams who are going to be doing the work revisit the estimates

Committing to the Team

Team members are making a verbal commitment to their team when they state what they are going to do today, creating an opportunity for the rest of the team to confirm they met their commitments yesterday.

Valuing the Whole Team

SM should focus on an “us” versus “them” attitude in the distributed team, due to more delays in communications & fewer opportunities to work together Scheduling for Teams with No Overlapping Work Hours.

Alternate meeting time

The distributed team holds one Sprint Review meeting during the normal workday for part of the Scrum Team and holds the other Sprint Review meeting during the normal work hours of the other part of the Scrum Team.

Building Trust

SM needs to develop a sense of trust and honesty with one another, which in turn will lead to a wider degree of openness.

  • Single Backlog for Multiple teams – The different skill sets in the team needs to deliver user stories that are available across each distributed location
  • Separate Backlog for Multiple teams – The Scrum teams work independently from one another and have their own individual Sprint backlogs, but the Sprint dates are the same marking their interdependencies and risks in the Sprint preplanning sessions or in a Daily Scrum of Scrums.
  • Reviewing Changes Based on Stakeholder Feedback – The team would review changes made since the preplanning meeting, and the PO would confirm the priorities of the Product backlog.
  • Verifying Progress – Tasks not opening and closing regularly are an early sign the team may be going off track. Team members not showing regular progress may be facing outside distractions the SM should reduce or remove.
  • Transparency – Distributed agile teams should use project management tool to identify tasks that are open, in progress, and completed so everyone is aware of the current status.

More on the Sprint Review and Conclusion next!