SPaMCAST 540 – From Chaos to Successful Distributed Agile Teams, An Interview with Mark Kilby and Johanna Rothman

http://www.spamcast.net

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 540 features our interview Mark Kilby and Johanna Rothman. Johanna, Mark, and I discussed their new book, From Chaos to Successful Distributed Agile Teams, Collaborate to Deliver (Buy your copy here: https://amzn.to/2Omur23). Distributed agile teams are a fact of life; Johanna and Mark provide an extraordinary amount of wisdom for making distributed teams exceptional.   

Johanna’s Bio

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems, resolve risks, and manage their product development.

Johanna was the Agile 2009 conference chair and was the co-chair of the first edition of the Agile Practice Guide. Johanna is the author of 14 books that range from hiring, to project management, program management, project portfolio management, and management. Her most recent books are From Chaos to Successful Distributed Agile Teams (with Mark Kilby) and Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.

Read her blogs, email newsletter, and more information about her books at www.jrothman.com 

Mark Kilby Bio

With over two decades of experience in agile principles and practices, Mark Kilby has cultivated more distributed and dispersed teams than collocated teams.  He has consulted with organizations across many industries and coached teams, leaders, and organizations internally. Mark also co-founded a number of professional learning organizations such as Agile Orlando, Agile Florida, Virtual Team Talk, and the Agile Alliance Community Group Support Initiative among others.  His easy-going style helps teams learn to collaborate and discover their path to success and sustainability. Mark shares his insights on distributed and agile teams in dozens of articles in multiple publications. Most of his latest ideas and developments can be found on www.markkilby.com

Re-Read Saturday News
We have been re-reading Malcolm Gladwell’s The Tipping Point over the past 10 weeks.  When considering how I would wrap up the re-read I had to fight the urge to parrot back the findings Gladwell identified in the conclusion: a few people are critical and that people’s biases matter. Real life intervened and I applied the ideas in the book!

We need to choose the next book in the Re-read Saturday Series. Steven Adams has requested a referendum on the next book.  Mr. Adams has always provided sage advice, therefore, a poll we will have! The poll will be open for two weeks. Vote for your two favorites.

 

Distributed Stand Up Meetings

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively are the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective for making daily stand-ups work for distributed teams include:

 

Extreme Programming Explained, Second Edition: Re-Read Week 12 (Chapters 22 – 23)

This week the re-read of Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005) tackles Chapters 22 and 23. Two more weeks until we shift gears and start reading The Five Dysfunctions of a Team (if you do not own a copy, it is time to order one – use the link to support the blog and podcast).  Back to XP Explained; Chapter 22 considers the implications of offshore development on the application of XP.  Distributed team members does not preclude using XP.  Chapter 23 waxes philosophically on the programming.  At its core, programming is a discussion of people and behavior more than technique and tools.

Chapter 22: Offshore Development
In the late 20th and early years of the 21st centuries, the software industry was still learning how to grapple with offshore development. Distributed teams became a popular idea.  Whether a team was partially in India, Belarus or Iowa has always been less of an issue than how power and decision making is distributed.  Beck makes the point that even the word ‘offshore’ is a loaded concept that implies an imbalance of power (Beck prefers the term “multisite”). Teams with imbalance of power and decision making will be less effective because parts of the team will be demoted to order takers rather than collaborators.  The values of XP (and therefore XP as an approach to development) are just as relevant in multisite development. When embracing XP in a multisite environment the values and principlesof XP provide a stable underpinning to tailor the core and ancillary practices of XP.

The practices of XP, as we have noted before, are merely tools to implement the values and principles of XP.  There is no perfect set of XP practices, but rather each organization needs to implement XP based on their own context.  Multisite development is just another context. As an example, Beck suggests that in a multisite environment planning might have to occur multiple times a week rather than once every sprint or iteration.

The goal of multisite development is to increase productivity.  There are numerous ways to state this goal, such as to get more with less or to improve the value of software delivery; however as we have explored in previous essays, all of these statements boil down to improved productivity.  One way to measure and provide evidence of improved productivity is to reduce team sizes while increasing throughput. The second goal of multisite development is to reduce waste in software development rather than trying to put up barriers that keep work in places with low productivity or high production costs. Everyone should consider the second goal as a clarion call for continuous improvement (process, people and technology) to protect competitiveness and jobs.
 
Side Note:  Even though XP Explained, Second Edition was published in 2005, the state of multisite development is still mixed.  I have worked as a consultant for many organizations that leverage multisite development.  Done well multisite site development often offers significant value, but many organizations approach the model poorly and therefore don’t get the value they expect.

Chapter 23: The Timeless Way of Programming
When I read this chapter I was struck by how different the two editions of XP Explained are when compared. The second edition far more philosophically in tune with the world of software development of the early 21st Century (i.e. now). Beck begins the chapter by using the analogy of the power differential between a structural architect and the person for whom he or she is designing the space.  The architect has the upper hand, unless a balance of between the parties can be established.  In the software development environment, the relationship between the business and development, in which the business describes both what they want and the how, when and cost of what will be delivered, is a reflection of a similar power imbalance.  A healthier relationship requires a balance between the business and technical view that maintains the integrity of the overall system.

The values, principles of XP promote the aim of a balanced relationship between the business and development. XP describes an environment in which the team includes technical and business personnel.  XP provides an environment in which developers can develop and excel technically so decisions about the business can be left to the business-oriented part of the team. As Beck puts it,”sharing power is pragmatic, not idealistic.” In the end XP is discussion of empowering people versus primarily being a discussion of tools and techniques.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 – 3

Week 3, Chapters 4 – 5

Week 4, Chapters 6 – 7  

Week 5, Chapters 8 – 9

Week 6, Chapters 10 – 11

Week 7, Chapters 12 – 13

Week 8, Chapters 14 – 15

Week 9, Chapters 16 – 17

Week 10, Chapters 18 – 19

Week 11, Chapters 20 – 21

Remember  we are going to read The Five Dysfunctions of a Team by Patrick Lencioni next.  This will be a new book for me; therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks, we will begin to read the book together.

 

Stand-Up Meetings

Preparing for a Daily Stand Up

The daily stand-up meeting is the easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.

• The team gathers on a daily basis.
• Each team member answers three basic questions:
  • What tasks did I complete since the last meeting;
  • What tasks do I intend to complete before the next meeting, and
  • What are the issues blocking my progress?
• The meeting ends, team members return to work OR discuss other items.

 

Demonstrations in Distributed Teams

The demonstration needs to work for everyone, no matter where in the world you are.

Demonstrations are an important tool for teams to gather feedback to shape the value they deliver.  Demonstrations provide a platform for the team to show the stories that have been completed so the stakeholders can interact with the solution.  The feedback a team receives not only ensures that the solution delivered meets the needs but also generates new insights and lets the team know they are on track.  Demonstrations should provide value to everyone involved. Given the breadth of participation in a demo, the chance of a distributed meeting is even more likely.  Techniques that support distributed demonstrations include:

1. More written documentation: Teams, especially long-established teams, often develop shorthand expressions that convey meaning fall short before a broader audience. Written communication can be more effective at conveying meaning where body language can’t be read and eye contact can’t be made. Publish an agenda to guide the meeting; this will help everyone stay on track or get back on track when the phone line drops. Capture comments and ideas on paper where everyone can see them.  If using flip charts, use webcams to share the written notes.  Some collaboration tools provide a notepad feature that stays resident on the screen that can be used to capture notes that can be referenced by all sites.
2. Prepare and practice the demo. The risk that something will go wrong with the logistics of the meeting increase exponentially with the number of sites involved.  Have a plan for the demo and then practice the plan to reduce the risk that you have not forgotten something.  Practice will not eliminate all risk of an unforeseen problem, but it will help.
3. Replicate the demo in multiple locations. In scenarios with multiple locations with large or important stakeholder populations, consider running separate demonstrations.  Separate demonstrations will lose some of the interaction between sites and add some overhead but will reduce the logistical complications.
4. Record the demo. Some sites may not be able to participate in the demo live due to their time zones or other limitations. Recording the demo lets stakeholders that could not participate in the live demo hear and see what happened and provide feedback, albeit asynchronously.  Recording the demo will also give the team the ability to use the recording as documentation and reference material, which I strongly recommend.
5. Check the network(s)! Bandwidth is generally not your friend. Make sure the network at each location can support the tools you are going to use (video, audio or other collaboration tools) and then have a fallback plan. Fallback plans should be as low tech as practical.  One team I observed actually had to fall back to scribes in two locations who kept notes on flip charts by mirroring each-other (cell phones, bluetooth headphones and whispering were employed) when the audio service they were using went down.

Demonstrations typically involve stakeholders, management and others.  The team needs feedback, but also needs to ensure a successful demo to maintain credibility within the organization.  In order to get the most effective feedback in a demo everyone needs to be able to hear, see and get involved.  Distributed demos need to focus on facilitating interaction more than in-person demos. Otherwise, distributed demos risk not being effective.

 

Distributed Agile: Retrospectives

Retrospectives are reflective!

 

Retrospectives are the team’s chance to make their life better. Process of making the team’s life better may mean confronting hard truths and changing how work is done. Hard conversations require trust and safety. Trust and safety are attributes that are hard to generate remote, especially if team members have never met each other. Facilitation and techniques tailored to distributed teams are needed to get real value from retrospectives when the team is distributed.

1. Bring team members together. Joint retrospectives will serve a number of purposes including building relationships and trust. The combination of deeper relationships and trust will help team members tackle harder conversations when team members are apart.
2. Use collaboration tools. Many retrospective techniques generate lists and then ask participants to vote. Listing techniques work best when participants see what is being listed rather than trying to remember or reference any notes that have been taken. I have used free mind-mapping tools (such as FreeMind) and screen-sharing software to make sure everyone can see the “list.”
3. Geographic distances can mask culture differences. The facilitator needs to make sure he or she is aware of cultural differences (some cultures find it harder to expose and discuss problems). Differences in culture should be shared with the team before the retrospective begins. Consider adding a few minutes before beginning retrospective to discuss cultural issues if your team has members in or from different counties or if there are glaring cultural differences. Note the same ideas can be used to address personality differences.
4. Use more than one facilitator. Until team members get comfortable with each other consider having a second (or third) facilitator to support the retrospective. When using multiple facilitators ensure that the facilitators understand their roles and are synchronized on the agenda.
5. Consider assigning pre-retrospective homework. Poll team members for comments and issues before the retrospective session. The issues and comments can be shared to seed discussions, provide focus or just break the ice.

All of these suggestions presume that the retrospective has stable tele/video communication tools and the meeting time has been negotiated. If participation due to attendance, first ask what the problem is and if the problem is that attending a retrospective in the middle of the night is hard then consider an alternate meeting time (share the time zone pain).

Retrospectives are critical to help teams grow and become more effective. Retrospectives in distributed teams are harder than in co-located teams. The answer to being harder should be to use these techniques or others to facilitate communication and interaction. The answer should never be to abandon retrospectives, leave remote members out of the meeting or to hold separate but equal retrospectives. Remember, one team and one retrospective but that only work well when members trust each other and feel safe to share their ideas for improvement.

 

Distributed Agile: Backlog Grooming Meetings

Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

There are two reasons to hold backlog grooming meetings. The first is to make sprint planning more efficient and effective. The second reason is to make sure you understand your backlog. When teams don’t spend the time needed to groom the backlog, planning meetings can be very tense and extend for hours . . . and hours. Backlog grooming sessions can be whole team activities (rare) or sub-team activities (more common). The most common technique used to generate a sub-team for grooming is the Three Amigos (or some variant). The tallest hurdle all distributed teams face is ensuring effective communications, followed quickly by staying focused on the task at hand. Many of the same techniques we discussed for sprint planning in distributed teams will be effective, however, backlog grooming has a few unique twists.

 

Distributed Agile: Daily Stand-up Meetings

Stand-ups are best on your feet!

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively are the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective making daily stand-ups work for distributed teams include:

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 option). One usable solution that can be tried when distributed teams can’t overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
2. Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will 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 that 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 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 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 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 as distributed teams.

5. 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.
6. 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 includes the willingness to ask for help and to provide help to team members.
7. 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 the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to 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.
8. 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 CAN’T communicate.

Stand-ups are nearly ubiquitous in Agile. I would do stand-ups even if I were not doing 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.

 

Distributed Agile: Sprint Planning

#6 Make sure the telecommunications tools work.

In Distributed Agile: Distributed Team Degree of Difficulty Matrix, I described the many flavors of distributed Agile teams and the complexity different configurations create. While all things being equal, distributed team are less effective than collocated teams. Never the less, distributed Agile with teams spread across countries, continents and companies have become a fact of life. There are techniques to help distributed Agile teams become more effective. In an environment using Scrum, the first formal activities for most team’s is sprint planning. There are numerous techniques that can help make distributed Agile more effective. These techniques include:

1.   Bring the team physically together. Co-location, whether for a single sprint or some periodic basis, will increase the team’s ability to understand each other and know how to work together more effectively.
2.   Develop a sprint planning checklist. The process of getting together and planning is a fairly predictable process. Capture the typical preparation and meeting tasks and make sure they happen. Items can include booking rooms, securing video or telecom facilities, publishing an agenda with breaks and more.
3.   Review the definition of done. Ensure that everyone understands the organization’s definition of done before the starting to plan. The definition of done will help the team know the tasks they need to complete during the sprint to meet the organization’s (or product owner’s) process standards.
4.   Focus on the stories. Don’t let distractions get in the way of planning. Before beginning the planning session, review the process that will be followed with the entire team. Make sure that planning the next sprint is the only topic on the agenda.
5.   Ensure that the stories have been properly groomed. The stories that the team will accept and plan need to be properly formed and have acceptance criteria. This generally means that the stories that are most apt to be accepted by team (and a few more) need to have been through a grooming session. Make this a prerequisite for the planning meeting.
6.   Make sure the telecommunications tools work and have a backup. Distributed planning means that all of the team will be using the phone or video conference. Make sure they are set up and tested. Also always have a backup plan in case your favorite collaboration tool fails because sooner or later it will. Planning is a whole team activity and when the whole team can’t participate planning, it will lose effectiveness.
7.   Everyone should understand the big picture. Have the product owner provide an overview of the goals of the project, and how the current sprint will support those goals. Repeating the big picture will provide the team with a common touch point to validate progress.
8.   Use physical tools for interaction. Physical tools, like flip charts and card walls, can be difficult when many locations are involved in sprint planning. However, when possible, use physical tools like flip charts and whiteboard and then use webcams (preferable) and cameras to share data. Have one location scribe one story and then switch locations for the next story.
9.   Try multiple facilitators. When a team is evenly distributed between two locations consider having another scrum master act as a second facilitator to ensure everyone stays on track. Similarly, have the Scrum master rotate between locations to facilitate the planning session. This can be very effective in helping each location feel connected.
10.Remember that sprint planning is a team meeting. Make sure everyone is involved.

Sprint planning, done well, helps a team understand what they have to do in order to consider a story complete, both from a functional and technical perspective. Distributed Agile teams will need to focus on making sure that everyone is involved and a part of the planning process. Remember to plan for planning, because when you are on the other end of a phone or videoconferencing the tools, process and logistics can make or break the meeting!

 

Daily Stand-Up Meetings: The Most Ubiquitous Agile Practice

Preparing for a Daily Stand-Up

The daily stand-up meeting easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.