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. (more…)

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 (more…)

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! (more…)

Shadow

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: (more…)

Preparing for a Daily Stand Up

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.

(more…)

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 21nd. 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.

 

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

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.