SPaMCAST 539 – Agile Assessments, Distributed Agile, Essays and Discussions

http://www.spamcast.net

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

SPaMCAST 539 features our essay titled, Assessment and Continuous Process Improvement. Assessments and continuous process improvement are intertwined because assessments are both a source of ideas and a tool to validate change and other experiments. Other essays that have appeared on the SPaMCAST blog on agile assessments  include:

Assessment and Continuous Process Improvement – https://bit.ly/2UU8mdI

Components Of A Solid Assessment Plan https://bit.ly/2YsHqnM

Assessments: Being or DOing https://bit.ly/2HGOEiK

An Assessment: A Mall Map For Change https://bit.ly/2TX8BbJ

We will also have part 2 of Susan Parente’s discussions on distributed agile.  This week we will focus on tools. Susan reminds us that unless you spend time building trust and learning how to communicate, a tool won’t solve a communication problem.

Re-Read Saturday News
This week we conclude the re-read portion of our tour through Malcolm Gladwell’s The Tipping Point by tackling both the conclusion and the afterword. The Tipping Point is a theory that viral change—epidemics, in Gladwell’s words—can be caused and shaped by few actions and people. The Law of the Few tells us that connectors, mavens and salespeople can affect whether or not a concept, idea or movement moves across the tipping point and becomes an epidemic.

 

SPaMCAST 535 – Kanban To The Rescue, Distributed Agile. Essays and Discussions

http://www.spamcast.net

Direct Playback

Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Listen on Spotify!

SPaMCAST 535 features our essay spawned when I was asked to help a Scrum Master who said: “I messed up a scrum team, should I do kanban?”  There is not a straightforward answer because regardless of the path forward there are people issues that need to be dealt with first.

Also in this podcast, we have a visit from Susan Parente and her ‘I am not a Scrumdamentalist’ column.  In this installment, Susan discusses distributed Agile. Agile on distributed teams is often discussed in hushed tones.  Susan brings the topic out into the open and provides excellent advice.

Re-Read Saturday News
We continue our re-read of The Tipping Point by Malcolm Gladwell. Chapter Four of Malcolm Gladwell’s The Tipping Point begins the discussion of the role of context in approaching a tipping point.  Stop borrowing your best friends copy and buy a copy of the book for yourself!  

Check out the current entry of Re-Read Saturday at www.tcagley.wordpress.com

 

SPaMCAST 419 – Notes on Distributed Stand-ups, QA Corner, Configuration Management, Software Senesi

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 419 features our essay on eight quick hints on dealing with stand-up meetings on distributed teams. 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. Remember an update on the old adage: distributed teams, you can’t live with them and you can’t live without them.  

We also have a column from the Software Sensei, Kim Pries.  In this installment, Kim talks about the  Fullan Change Model. In the Fullan Change Model, all change stems from a moral purpose.  Reach out to Kim on LinkedIn.

Jon M Quigley brings the next installment of his Alpha and Omega of Product Development to the podcast.  In this installment, Jon begins a 3 part series on configuration management.  Configuration management might not be glamorous but it is hugely important to getting work done with quality.  One of the places you can find Jon is at Value Transformation LLC.

Anchoring the cast this week is Jeremy Berriault and his QA Corner.  Jeremy explored exploratory testing in this installment of the QA Corner.  Also, Jeremy has a new blog!  Check out the QA Corner!

 

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:

 

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.

 

SPaMCAST 351 – Distributed Agile, Illusion of Control, QA Corner

http://www.spamcast.net

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 351 includes three columns.  The first is our essay on distributed Agile. What is distributed Agile? The phrase “distributed Agile” is often used indiscriminately; therefore definitions can cover a wide range of situations and evoke a wide range of emotions. A precise definition encompasses three concepts. The first is a team, project or program that is using Agile techniques. The second is geographic distribution describing where team members are located. The location of team members in a distributed team can range from being spread across a single building to members sprinkled across continents. Finally, the third is organizational distribution, meaning that teams can be comprised of members from different companies. No matter the definition, distributed Agile is different.

The Software Sensei, Kim Pries dives into the Illusion of Control.  Kim reminds us to drop the egos before you start working and choose your weapons unemotionally!

Jeremy Berriault brings a new installment of his QA Corner.  Jeremy discussed why testing is not just a random event. Testing requires planning or you will waste time, effort or your quality.

Call to Action!

I have a challenge for the Software Process and Measurement Cast listeners for the next few weeks. I would like you to find one person that you think would like the podcast and introduce them to the cast. This might mean sending them the URL or teaching them how to download podcasts. If you like the podcast and think it is valuable they will be thankful to you for introducing them to the Software Process and Measurement Cast. Thank you in advance!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing.  This week we tackle the essay titled “The Surgical Team”!

The Re-Read Saturday and other great articles can be found on the Software Process and Measurement Blog.

Remember: We just completed the Re-Read Saturday of Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement which began on February 21^nd. What did you think?  Did the re-read cause you to read The Goal for a refresher? Visit the Software Process and Measurement Blog and review the whole re-read.

Note: If you don’t have a copy of the book, buy one. If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Upcoming Events

Software Quality and Test Management Conference
September 13 – 18, 2015
San Diego, California
http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending!

I HAVE A SPECIAL DISCOUNT CODE. .  . just ask!

More on other great conferences soon!

Next SPaMCAST

The next Software Process and Measurement Cast features our interview with Gil Broza.  We discussed Gil’s new book The Agile Mindset.  Teams and organizations with an Agile mindset deliver more value; however many in the Agile community don’t know or don’t embrace an Agile Mindset.  Gil’s new book explains the concept of the Agile Mindset and how you can find it!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 

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: Checklist of the Basics

Hydrogen is elementary!

Hand drawn chart Saturday.

In Scrum there are four-ish basic meetings. They are sprint planning, daily stand-up, demonstrations, retrospectives and backlog grooming (the “ish” part). Whether distributed or co-located, these meetings are critical to planning, communication and controlling how Agile is typically practiced. Getting them right is not optional, especially when the Agile team is distributed. While there specific techniques for each type of meeting (some people call them rituals) there a few basics that can be used as a checklist. They are:

• Schedule and invite participants. Team members are easy! Schedule all standard meetings for team members upfront for as many sprints as you are panning to have. As a team, decide on who will participate in the demo and make sure they are invited as early as possible.
• Review the goals and rules of the meeting upfront. Don’t assume that everyone knows the goal of the meeting and the ground rules for their participation.
• Publish an agenda. Agendas provide focus for any meeting. While an agenda for a daily stand-up might sound like overkill (and for long-term, stable teams it probably is), I either review the outline of the meeting or send the outline to all participants before the meeting starts.
• Check the tools and connections. Distributed teams will require tools and software packages; including audio conferencing, video conferencing, screen sharing and chat software. Ensure they are on, connected and that everyone has access BEFORE the meeting starts.
• Ensure active facilitation is available. All meetings are facilitated. Actively facilitated meetings are typically more focused, while un-facilitated meetings tend to be less focused and more ad-hoc. Active or passive facilitation is your choice. Distributed teams should almost choose facilitation. If using Scrum, part of role of the Scrum master is to act as a facilitator. The Scrum master guides the team and participants to ensure all of the meetings are effective and meet their goals.
• Hold a meeting retrospective. Spend a few moments after each meeting to validate the goals were met and what could be done better in the future.

Agile is not magic. All Agile teams use techniques that assume the team has a common goal to guide them and then use feedback generated through communication to stay on track. Distributed Agile teams need to pay more careful attention to the basics. The Scrum master should strive to make the tools and process needed for all of the meetings fade into the background; for the majority of the team the end must be more important than the process.

 

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: Demonstrations

Demonstrations!

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.