Why Agile Teams Often Don’t Thrive


On TUE May 19, we hosted Ron Jeffries (yes the guy who has been building software longer than you have been alive) at DFW Scrum. Ron is a frequent visitor of our group and has provided unbelievable guidance and direction to my own teams in our transition to Scrum and agile development practices.

 Ron spoke to our group on “Why so many agile teams often don’t thrive”. I think someone who actually helped manufacture the “Agile Manifesto” would probably be a good source of information on helping us identify our pitfalls in adoption and progress.

 Ron specified 2 main points to this actual topic:

  1. Teams don’t know how to ship software every sprint

  2. Cultural changes necessary do not take place (like helping a team become better at shipping software each sprint)

 Ron’s points above aren’t really the meat to this topic in my opinion. I had a few people struggle with what Ron was trying to convey and I immediately came to his defense and asked “don’t you guys get it?”. Obviously not, therefore, this blog post. Ron’s message hit me right in the sweet spot and validated my fairly close alignment with his views on agile development practices (he obviously has been a big influence in my journey).

 The point? We spend so much “flipping” time (Ron would have used a different word) on making sure our Scrum Masters, Product Owners, and Organization Stakeholders are prepared for the agile journey that you know who we leave out of this preparation? You got it…THE TEAM!

 If we break Scrum down into its components, we “should” have 1 Product Owner, 1 Scrum Master, and 3-9 Development Team members. Where do you think the force lies in where we spend time in equipping the teams? That’s right, the backlog (which is important), how will the business react, will they engage, do we have the roles required, how will we estimate, how we will plan a roadmap, so on and so forth.

 Those are all important questions to ask, but you know which artifact in Scrum we have lost focus on? The actual increment. The increment is the most important artifact in Scrum. If a team can’t ship software each sprint, they can’t tell a story; thus they can’t get the trust and confidence needed to let the business people focus on the what; letting the teams focus on the how. Too often the teams retreat into a hell where they need to know everything up front because we leave no room for failure, mistake, or God forbid, a misunderstanding in the actual requirement.

 Ron started the talk with relating to why Kent Beck created XP (eXtreme Programming). Basically to protect the team. I have a similar mindset in my transitions to agile and will usually build an API translation layer of communication over the team to protect them as much as possible from the cruft the organization might place on them. Our goal? Ship software! Not time-sheets, estimations, roadmap planning, meetings; SHIPPING SOFTWARE!

 Product Development is a collaborative game. Each team has different skill sets, each human brings a particular experience and skill-set to the team. What we should focus on in our agile adoption is “do these teams have the skills necessary to refactor and work incrementally to deliver slices of software to a tested/integrated environment every sprint”?

 Most of the time, the answer is no, but we will spend all kinds of money on the process, the roles, and the PMO type communication abstraction layer to ensure our teams can be left alone. As they are left alone, they struggle greatly in the organizations deployment, branching, merging, and build strategies. Please don’t misunderstand, I truly believe a team needs to provide the level of transparency to the business and PMO group on our progress, but too often this turns into an inordinate amount of work for the team.

 Ron painted a picture about a company party. Most of the time you find people socializing and talking about business. You usually find the development team folks bunched up together talking about technology and cool patterns they learned over a hack-a-thon project. They do this because they are passionate about the technology in their job and solving problems. Let’s incubate that environment and provide more opportunities for these folks to learn more about technical practices that encourage quick delivery. Branching/Merging techniques that allow us to receive changes frequently to minimize conflicts. The nitty gritty of software development.

 Ron encourages the various groups in Scrum (Scrum AllianceScrum.org, etc…) to think of ways we can foster growth in engineering practices. Let’s build more programs around the team and not just the Scrum Master / Product Owner.

When you go back and look at your teams, let’s see how much extraneous work we have around these folks that could be making them unhappy and uninspired in their quest to build innovative products. If your development environments are a large part of the problem, are we equipping the team with knowledge on how to incrementally refactor, incrementally make better paths to production, etc…?

 Back to Ron’s message, teams often don’t thrive because we don’t equip them with the knowledge and skills of how to incrementally build software. We focus on so much other activities and events in Scrum, that we tend to loose site of the most important thing, the increment. Ron is on a mission to help the Scrum Alliance and other organizations to start focusing on these types of activities that allow Developers an opportunity to show skills based on industry practices that can be learned through various techniques.

 I have an old saying in service organizations that says “if you aren’t servicing the customer directly, you better be servicing someone who is”. In Scrum, I can say “if you aren’t servicing the development team directly, you better be servicing someone who is”.

 We are in the business of shipping software, therefore, we better be the best shippers of software that we can. Are you?

April Dallas Recap: What Makes a Good Team Room?

A big thank you to everyone who attended and contributed to this meeting!  This session was all about sharing our experiences with team rooms—the challenges in creating them, characteristics that make for good team rooms, and even having breakout spaces where team members can work solo or in smaller groups as needed.  A few members shared photos of their team environments, and Ty captured notes on the whiteboards of the group discussion:

March Dallas Recap: Building Continuous Delivery

Allen Moore, QA Strategist

Allen Moore, QA Strategist

Continuing on a theme of QA/testing, in March we had DFW Scrummer Allen Moore share his experience in implementing continuous delivery.  The full title of the session was “Building Continuous Delivery: A Retrospective (or how a QA Strategy succeeds without any “QA” personnel).  His story is particularly interesting as he is the only person with “QA” in his title at his company—Allen is a QA Strategist and defines the quality processes, cultivates a culture of quality, builds continuous delivery and automated testing frameworks and educates the team in testing practices and habits.

For the past two years Allen has worked with a great team to define and implement continuous delivery, and his presentation reflected what worked well and what he would do differently next time.  It was a great example of how people can work together to learn new skills, implement new technologies, and improve processes to deliver higher quality product to better serve customers’ needs.  Thank you, Allen, for sharing your experience and expertise with us!

February Dallas Recap: Discover the Power of Pair Testing

In February, we were fortunate to have DFW Scrummer Pradeepa Narayanaswamy present at our Dallas meeting. Agile teams are expected to deliver high quality product, and team members become more cross-functional and take ownership of quality. To address scarce testing talents within a team and an effective way to become more cross-functional, team members can pair up on testing efforts to ensure the shared eye on quality and learning.

Pradeepa talked about several pairing options and opportunities between various specialties in an agile team:

  • A programmer and a tester pairing can lead to clearer unit test names in plain English
  • Two testers pairing can lead to more comprehensive tests
  • A Product Owner and a tester pairing can lead to better acceptance criteria on product backlog items
  • A tester and operations pairing in a DevOps context can lead to better sanity tests/release testing for a smoother deployment
  • A UX person and a tester pairing can lead to better design of non-happy path scenarios

That’s a lot of greatness that can come from having a tester pair with someone! Each pairing greatly supports providing faster feedback and producing high quality product as a team. And to get started, Pradeepa shared a couple of tips:

DFW Scrum February

January Recap: Dallas and Southlake Learn about Conflict

Conflict. What comes to mind when you think about conflict? Do you view it as a problem to solve? Something to make go away?

What if you could welcome conflict as an urge for change?

This was the subject of an amazing conversation led by Lyssa Adkins in our January meeting. In her talk, A Step-by-Step Guide to Changing Everything About Handling Conflict, Lyssa showed that if we take a few simple steps, change is possible, and we could get to the harmony on the other side of conflict. The key?  “Get insanely curious.”

To learn more about the session, you can view Lyssa’s presentation, handout, and Chris Murman’s blog post about the meetup.

Lyssa is co-founder of the Agile Coaching Institute, and ACI will be offering its 3-day Coaching Agile Teams class in Dallas March 4-6.

Special Agile Events Coming to Dallas in March 2015

We’ve highlighted some upcoming agile events during our monthly meetups, and I know it can be difficult to remember the details later (especially the URLs).  Information about two special events coming to Dallas in March 2015 is below:

The first event is the Coaching Agile Teams class by the Agile Coaching Institute on March 4-6, 2015.  This three-day class 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.  Results in a class certification in Agile Coaching by the International Consortium for Agile within their Agile Facilitation and Coaching track.  Counts as 21 SEUs by the Scrum Alliance.

The second event is Scrum Day for Professionals by Scrum.org on March 27, 2015 at the Addison Conference Center.  Join Scrum.org’s world-class experts for a day of face-to-face learning!  Participate in advanced panel discussions and sessions with experts who’ve been there.  Gain insights into agile practices you can employ immediately, and network with other professionals over complimentary breakfast, lunch, and snacks.  If you have any of the Scrum.org’s Scrum certifications (PSM, PSPO, PSD), you can receive an extra $150.00 discount on your registration fee.


December Dallas Recap: Scrum and the 3 Pillars

To wrap up 2014, we reviewed scrum and the three pillars of empiricism—a topic that could be considered foundational to deeply understanding the framework and one that is often overlooked in favor of focusing on practices.  From the Scrum Guide:

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.

In order to do better today than we did yesterday, we need to not only learn new things but also remember what we’ve learned before. This topic offered a bit of something new and something old for our attendees.

DFW Scrum-AndyDFW Scrummer Andy McKnight presented the night’s topic and included a group game: without use of a thermostat, determine what types of things you would take into consideration to maintain the temperature in a 20×20 room. How would you inspect and adapt to maintain the temperature? The ideas from the group were quite creative!

A thermostat inspects and adapts, and it provides transparency. These are the three pillars of empiricism that are the basis of scrum.  According to Ken Schwaber and David Starr,

Opacity when inspecting an Increment is like covering a thermostat with a cold, wet washcloth. The thermostat doesn’t have the correct understanding of the actual room temperature, and would incorrectly initiate heating when it should be cooling.


Without transparent Increments, the stakeholders don’t have a correct understanding of what is actually happening, and may incorrectly take actions that don’t make sense.


In short, without full transparency, the ability of the teams to inspect and adapt effectively is lost.

Without empiricism, we run the risk of this:

I prefer meeting with fellow DFW Scrummers to enjoy this:

DFW Scrum-cupcakes

Thank you to everyone who attended our meetups in 2014. This year saw the expansion of our group with the addition of a second location, and more of our members helped by facilitating small group discussions, answering questions and sharing experiences, and presenting topics. We are blessed to be part of such a strong and thriving agile community, and we look forward to seeing you in 2015!