Recap of Dallas’s July meeting: Overcoming the fear of Sprint Retrospective

July’s topic was posted by a community member on our meetup site, and after receiving a number of votes, we decided to make it the focus of a Wisdom of the Crowd night. What’s a Wisdom of the Crowd night? It’s one with no formal speaker or presentation—we enable our community to share their experiences and questions to generate new ideas and learning for all of us! We use an open space format to allow for deeper discussions of subtopics in smaller groups; if a member is interested in more than one subtopic or isn’t engaged in the group he’s in, he can move to another group without questions or judgment. Best of all, each group shares its findings at the end of the night with everyone, so we can all benefit from their learnings.

The meeting topic was Overcoming the fear of Sprint Retrospectives:

The sprint retrospective is by far the most underutilized and under appreciated meeting. Team members dread to go these meetings. Every Scrum Master has his own technique on how he overcame this and there is always room to grow.

We kicked off with some of the questions on our minds and split into multiple groups based on which question we wanted to explore further. The groups had rich discussions and came up with so many ideas that they used the whiteboards to capture them:

DFW Scrum - retrospectives 2 DFW Scrum - retrospectives 3DFW Scrum - retrospectives 4DFW Scrum - retrospectives

DFW Scrum – Second Quarter Summary

Here’s a recap of our meetings for the quarter:

April: Definition of Done, Chris Murman

Many companies practicing agile talk about the definition of done, but how many teams adhere to it on a sprint-by-sprint basis? Expectations that are either unmet, not communicated, or mismanaged are usually the source of our problems.

Chris presented some practical ideas on how to define “done” in your organization and didn’t stop there. He presented a bigger idea that surrounded the topic and gave everyone something to take back to their offices.

May: Using NPS Scoring at Sprint Reviews with Customers, Simon Cockayne

It’s extremely difficult to understand the link between a given user story and the money that could be saved/made by customers. But could customer happiness serve as a proxy to the actual or perceived value that the customer sees? Could we determine how happy each delivered user story made the customer?

So Simon introduced a Net Promoter Score (NPS) approach to determine how happy customers were with a delivered user story in a sprint review. NPS is based on a direct question: How likely are you to recommend our company/product/service to your friends and colleagues? The scoring for this answer is most often based on a 0 to 10 scale.

The results were wonderful:

  • customers were super keen to try something new.
  • the scores showed that they LOVED the stuff we were doing.
  • the scrum team was STOKED to see the high scores–that helped boost scrum team morale in the next sprint.
  • customers started interacting with each other as they discussed the value they perceived, lots of good spirits and good humor, to boot.

June: You Want to Use Scrum, You are Told to Use CMMI (How They can Work Together?), Neil Potter

The CMMI-DEV model is a collection of practices aimed at organizations that develop products, systems and IT solutions. The model is organized into five levels; each level defines more advanced practices to improve schedule, budget, risk and quality performance. The levels provide a road map for sustained incremental improvement.

CMMI practices can be implemented within any life cycle or methodology (such as Scrum, Waterfall, Spiral or Incremental). The benefits from using CMMI Level 2 and 3 practices are:

  • Clarify customer requirements early
  • Scope, plan, estimate and negotiate work to manage expectations and achieve commitments
  • Track progress to know project status at any time
  • Maintain defined quality standards throughout the organization and report strengths and problems to management
  • Manage versions of documents and code so that time is not wasted using incorrect versions or recreating lost versions
  • Manage and coordinate multiple teams that have cross dependencies
  • Employ engineering practices for design, implementation, verification and testing to reduce defects
  • Use defect data to understand and manage work quality throughout the project
  • Collect lessons learned and project data to systematically improve future organizational performance

For more information, view Neil’s presentation here.

Certificate of Occupancy


Have you ever been in your building and noticed a “Certificate of Occupancy”? These gems enforce a safe occupancy number that are built around fire codes. How many people could realistically exit this building in the case of a fire? My question, as it relates to software development and Scrum Teams is; why don’t we use this same kind of approach to protecting the sustainable development pace for our team?

This came to me really quickly as our office is expanding. No matter what WE want to do, we are bound by the occupancy certificate stating that we can only fit X number of people in this building. If we violate that (and are caught) the consequences would be great with the city, but even greater if we did have a fire and were not able to get out. Part of Scrum’s role in our teams is to help us identify and stick to a constant and sustainable development pace (throughput). As such, we should have “certificates of occupancy” in place to help us legislate that rate. Most often however, we are constantly pressed by management or our Product Team to do more, regardless of the cost. Most teams are actually rewarded for their outstanding effort and exceeding their capacity. Don’t get me wrong, we want our Product Team to want the world and push us. But, what happens if you run your engine at 15,000 RPM for a long time? What happens when your CPU is at 100% capacity? What happens if the highway system is at 100% (or even more)? Things come to a screeching halt and permanent damage ensues.

People (like computers and engines) are not built to operate consistently at 100% capacity or more, and doing so has grave consequences for productivity in the long term. Helping a team become aware of their sustainable rate, and predicting delivery off of those metrics inherent in Scrum; help maintain that level of stability. The team has control over what to commit to and what to hold. The pressure is less because the backlog and roadmap are built with their sustainable pace in mind. Believe me, if you don’t give dates for delivery, someone will. So it might as well be the development team, armed with great historical evidence of their ability to deliver as well as planning deliveries based on those realities and accomplishments.

I am certainly not saying there isn’t times where we do come together and work extra hard to get things done. I’m just saying those times have to be throttled and well understood by everyone. In addition, we should be really good at what we do and have discipline and rigor in our processes. As we continuously improve and search for better and better ways to do things, we will be productive and increase our output within our sustainable rate.

If we wanted to have more than X people in our building, we could petition the city for a permit that would increase that number (or not). The burden of proof would be on us to indicate the value of such exercise and the safety measures we put in place to allow the increase. The point is, we just can’t arbitrarily state “we need to work harder this sprint to get Y done”. Next time it will be “Z”, “A”, and “B”. That will never go away. Put checks and balances in place to ensure when you violate the sustainable and constance pace in Scrum, that we recognize the impact of that and that we are doing it for real reasons. If you want to increase the certificate of occupancy in your backlog and sprints, do so with the team and build roadmaps based on sustainable pace. Running our engines at high RPMs should be the exception, not the rule.

The Flat Tire


In regards to Scrum, many people struggle to wrap their heads around the process. While it is a fairly simple framework with very little rules and prescription, it is very difficult to actually do; logistically speaking. Build a backlog…ok, well how do I do that? Have a sprint review…ok, well how do I do that?

What actually holds this thing together is the vision and goal of Scrum. The goal is to enable us to get / manage / expose our work in a consistent process while consistently increasing our Agile Engineering practices that will allow us to ship the most valuable software we can for our customers when we want to ship it. This implies that whatever is getting in the way of you shipping software needs to be resolved. Scrum’s goals are to actually expose all of those reasons why we can’t get our code from our developer’s machines into Production with little to no human interaction along the build, test, and deploy path.

Manual testing will eventually show you that you aren’t able to move quick enough each and every time you want to ship. Not having a good backlog before your next sprint will show you that you are very reactionary and as such aren’t able to ship valuable software each sprint. Scrum exposes those leaks and that’s a good thing, celebrate when you find an inefficiency; that is something that we can all fix and improve.

One of my close colleagues in the industry has always said that Scrum is like a syringe that injects Agility into the organization. I love that analogy; I have also thought of many myself. Scrum is like going to the tire repair center. If you suspect a leak in your tire, a lot of the times, you just don’t know where it is coming from. We take it to the professionals as they can expose the leak with a tried and true technique. Take the tire off, soak it in some soapy water, and voila’ your leak appears (or maybe several leaks appear). Now, we can actually fix those leaks and get the car back on the road. What if, we found those leaks, and simply just put the tire back on the car and said “yes, there are leaks, we just don’t have time to fix them now”. At that point, you would likely drive off and continue to waste time by putting air in your tires; only to have it leak out later. Worse, you could be left stranded on the side of the road because of a flat. The right thing to do is to stop down, fix the leak, and then move on.

Scrum exposes those leaks. We the people, still have to fix our problems. No one thing or process can fix our problems, we humans have to dig in and find out the best way to solve the problem. Scrum is that agreement between the team to react to things in an empirical way, not a planned/predictive way. Take the time to take the tire off the wheel, soak it in water, find the leaks, and fix them. Some leaks are so big that we have to replace the tire. That’s ok too, celebrate that we learned of that problem. Our goal is to ship valuable-quality software when we want to and leaks prevent that from happening. Fix the leaks.

Learning to be a better Facilitator and Coach

Transitioning to agile requires people to work differently and making the transition to become a great Scrum Master or Agile Coach can be difficult.  Attending a Scrum Master class is the beginning of the journey for many.  For those who wish to further their journey and deepen their skills, the Agile Coaching Institute offers intermediate level classes.
I am SUPER-EXCITED to share that Lyssa Adkins and Michael Spayd from the Agile Coaching Institute will be coming to Dallas the week of June 9th offering two of their classes: the 2-day Agile Facilitator and the 3-day Coaching Agile Teams.  You can sign up for one class or both, and registration is online at 
This is an incredible learning opportunity for agile practitioners, and I look forward to attending the classes myself.  The Agile Coaching Institute does offer certifications, which are explained in this video:

About the Agile Facilitator class:
The Agile Facilitator is for experienced Agilists who wish to dramatically increase their facilitation skills in general, especially as applied to Agile ceremonies, collaborative events and other team “moments of truth.” The workshop will focus on professional facilitation skills and techniques as applied specifically within the Agile context.  While mastering facilitation skills in the Agile context will require both time and practice, our class will allow you to:
  • Gain an in-depth and practical understanding of a wide array of techniques practiced by professional facilitators.
  • Understand and practice the art of collaborative meeting design, including the importance of smart preparation that will reduce overall cost and increase the effectiveness of your meetings.
  • Practice techniques for skillfully facilitating core Agile meetings and ceremonies with playfulness and a collaborative spirit, while still focused on key deliverables.
  • Gain rich, well-delivered feedback on your growing facilitation skills
  • Give you ideas for designing meetings in which the team interacts with the team so they can do the heavy-lifting.
  • Understand how to address some of the dysfunctional behaviors you see preventing your team from achieving maximum success.
  • Learn how to define, discuss, and ACHIEVE consensus with the team for faster and better decision making.
  • Come away with your own facilitator self-development plan.
About the Coaching Agile Teams class:
Coaching Agile Teams is for experienced Agilists who wish to dramatically increase their overall agile coaching skills, including in the areas of Teaching, Mentoring, Facilitation, and Professional Coaching. Further, the class covers basics of team dynamics, team startup/reset, the individual change cycle, helping people through agile role transitions, and working with team conflict. The course is highly interactive and experiential. While mastering agile coaching skills will require both time and practice, our class will allow you to:
  • Understand and utilize the four key Skill Areas and four Knowledge Areas applied by the best agile coaches (ACI’s Agile Coaching Competency Framework)
  • Practice techniques for deep listening and asking essential, powerful questions.
  • Practice the distinction between coaching and mentoring and know when to apply each most successfully.
  • Observe a live, professional coaching demo on a situation in the agile context.
  • Understand how to address some of the dysfunctional approaches to conflict  team’s sometimes develop.
  • Understand a model for human change and a method for working with such change
  • You’ll walk away from the course with your personal coaching improvement backlog – a tangible plan you can use to thoughtfully improve your coaching when you’re back on the job.

Does Your Team Have a Definition of Done?

Does your team have a definition of done? In the dictionary, the term done means:

“Having been carried out, accomplished, or finished”

Many teams struggle to know when they are done, whether it is from the user story clarity itself or the team’s engineering paradigms paired with the diligence they have established in DONEness.

Have you ever seen anyone say “That’s Done Done”, or even “That’s done, done, and done”? We should have one singular version of what DONE is and the entire team (all roles) stand behind that version as a filter for things they choose to demonstrate in their sprint review sessions. If the user story is not done, then don’t call it done, don’t split it up, just move it to the backlog for re-prioritization.

Having a definition of done allows you to start your strength training exercises in Agile Engineering. When you first start a work-out program, you have a fairly light regimen that allows you to lift weights, do cardio, and stretch without getting hurt. As you strengthen yourself, you start changing your regimen to have more discipline and rigor. You might add more days to the work-out, increase the weights, or even do complex aerobics.

The point is, if you don’t continue to escalate your work-out, you won’t get stronger. You have to exercise those muscles. At some point, they will reach their comfort zone and be able to perform your current work-out with minimal exertion. The point of increasing your work-out regimen is to get stronger and stronger.

The same holds for your definition of done. You have to start out where you are, but have the idea of where you want to go. Your definition of done should change overtime as you strengthen your Agile Engineering practices. Work those development muscles and become stronger and more Agile the more you add to your rigorous definition of done. Your customers, the business, and your team will thank you for it, I promise.

If your definition of done is the same now as it was 1-2 years ago, you aren’t Agile and you certainly aren’t improving. Measure it like velocity, the trend over time should show an upward slope, always increasing your team’s strength in doneness.

Achieving Success with Distributed Teams

On February 28, Josh Woodcock gave a presentation on his experience working with a fully distributed team and shared ideas on how agile can be successful in such situations. Even though Josh’s team is spread across the US, they have been able to create a virtual team room and share information by using video and online tools. Team members use webcams throughout the day, making them feel more connected to one another and promoting the type of osmotic communications found in physical team rooms. Team members also pair program by sharing screens.  By asking the question, “how would you handle X if the team was co-located?” Josh’s team has been able to find and use online tools to replicate as much of the co-located team experience as possible.  For many distributed teams that are struggling, using tools to ends up feeling like this:

That’s not how we’d want co-located teams to be, so why settle for that experience when we’re distributed?  Consider how something would work well for a co-located team and find the tools that work to support your team’s communication throughout the work day (suggestion: use video as much as possible and limit emails—rely on richer, synchronous communication when you can).

In Josh’s experience, finding the right tools to support his team has resulted in high-quality and frequent delivery of working software that delights their customers. For more information about the presentation, including a list of recommended tools, view Josh’s slides at

Since this topic had such a high interest from our members, we continued our discussion in March with an open space format.  We started off by sharing ideas and questions that we had and then formed smaller groups based on the following subtopics:

  •       How to effectively run the scrum ceremonies and communicate between ceremonies
  •       How to divide work
  •       How to handle cultural differences with the team
  •       How can the team support the Scrum Master and Product Owner

The discussions were lively, and each group reported out its findings.