Betsy the cow

by | Jan 9, 2009 | Experience | 1 comment

As an Agile coach I enjoy the opportunity to learn from people implementing scrum framework and incorporating Agile values and principles. In this process I come across interesting stories and metaphors. After an introductory training session with one team and some follow up coaching during sprint planning, Paul (team member) shared his impression of the situation the team was put-in with this new scrum and Agile thing –

Back on the farm, if a cow isn’t producing more milk than cost of the feed she eats, unless someone really likes scratching her between the ears as a pet, sooner or later she ends up as hamburger.

I must admit that when I heard of it for the first time, I felt very uneasy. It is a very blunt analogy getting straight to the primary design benefit of scrum – Maximize Return on Investment (ROI). If at the end of every sprint the organization does not believe it can get sufficient ROI over the cost of development, then there are “Or Else …” scenarios that the organization can pursue.

Scrum does not tell you about what you should do, it simply brings transparency into the system and provides opportunities for early adjustments.

The thing that concerned me was that the team had likened the “or else…” scenario with Betsy ending up on organization’s menu. At that time I expected the team to get over their initial fears and move forward with a more positive outlook. It was not to be so, a sprint later I saw a picture of cow-cuts on top their team task board.

Had this team drifted deeper and darker with Betsy’s supposed fate? 

Successful cross-functional teams that I worked with,  have a sense of identity that is separate from their job titles or departmental affiliations or other organizational chart bindings.  As a coach, the simplest thing that I have done to trigger such a sense of identity, is to facilitate scrum teams through an exercise to help them create their team name. Although I floated this idea of creating a team name to the team described above, they did not feel it was necessary for them to do so. Instead this team  had adopted Betsy as their team mascot and coalesced around the notion of saving Betsy from her predicament sprint after sprint after sprint.

Over the last 10 or so two week sprints, I have had the pleasure of working with this team intermittently and I have observed the team adopt Betsy into everything they do and innovate along the way.

Before I delve further, some context about this team is due. Each of the team members has a minimum of at-least 15 years of  software industry experience. The team works for a well known insurance provider and does sustainment engineering for all business processing applications. They interact with customer account managers that are transferring big organizational health care insurance benefits to be managed by their company, customer service personal that are serving individual insurance beneficiaries and operations support that manages changes to production systems. Like many scrum teams they are in a very complex environment. Their complexity is compounded by the urgency of fixes requested from the business side and from the necessity of their operations and DBA group to ensure quality of fixes. They are not immune from challenges associated with organization silo’s wherein the DBA group cannot dedicate any member to the scrum team so as to form a truly cross-functional scrum team. On the plus side they have an excellent scrum team very well supported by their ScrumMaster and ably directed by their Product Owner, who is from the business side of the organization.

So what does it mean to save Betsy within their context? There are many dimensions to addressing this question.

  • From a software delivery perspective, the team commits to delivering software product fixes and enhancements to production environment every sprint. I remember this interesting conversation where the team was discussing their definition of done. Question arose, whether they should commit against a definition of done when elements of done-ness, such as production database updates, are beyond the authorized scope of the team members (DBA group owns production updates). At the end of their dialogue every one in the team agreed that only software that is in use by end-users constitutes valuable software. Although they do not directly manage production updates, they believe it is their responsibility to shepherd updates into production environment. In effect, every sprint they committed against a definition of done that required product backlog items to be implemented in production environment. This required them to engage representative from DBA during their daily stand-up, working with the DBA group to work with their constraints, such as no production updates on Wednesdays & Fridays. Also building automation test scripts to validate quality prior to review by DBA’s, effectively reducing rework cycles.


  • Engaging sustained participation from business. Prior to their scrum implementation customer issues and requests from business side were some times, lost in the ether. It was not unusual for the team to come across requests or tickets that were more than a year old. Through regular prioritization by the product owner the team was able to focus on the highest priority fixes that needed to be addressed. The ScrumMaster was very effective at challenging the team to change long held organizational-cultural habits.  One such behaviour of their silo-ed environment was that of communicating ticket status through the bug tracking system. All too often tickets that were resolved and ready for functional acceptance were not looked at by the business person for closure. This resulted in delayed production updates for several resolved issues. Team members started interacting in face-to-face conversations with business people to better understand their tickets and following up with them to confirm functional acceptance. Such proactive steps drastically reduced wait times involved.


  • Complete transparency. Here’s a snapshot of their task board :

  • Being the only scrum team in their organization, sustaining healthy relationships within the team and with others who interact with the team is critical. One of their approaches is to manage this through recognition: Every sprint the team recognizes people who have contributed to save Betsy. This cute little award is given to people within the team or outside the team for their contribution towards saving Betsy.

  • Addressing root cause for recurring issues. The team routinely analyzes commonly recurring issues and implements fixes that addresses the root cause for these issues.


  • Having fun! team members flex their creative muscle every sprint by chronicling events of their sprints in news print format themed around Betsy, astutely weaving their sprint happenings with current affairs of the world at large.  Here are a few examples,

The team ScrumMaster, Stan’s favorite is this one where Betsy takes to skies. The entire success with scrum is really due to his efforts and leadership. He has been very open minded and very smart, to let the team run with Betsy and see how it would play out with the team and the rest of the organization. Its one thing to float an idea, and quite another to really figure out what is going to work, and what might not be a good idea to fit in with the bigger picture.

This approach at recording sprint facts and events is sooo innovative/cool/awesome that my team used this technique to do our sprint retrospective. During our retrospective we formed pairs and spent 30 minutes each to create our own version of scrum times. After that we shared our impressions of the sprint via the news-prints that we had created. It was a fun exercise and the discussions were so much richer as each pair accentuated aspects of sprint dearer to them.

There are many other things that directly or indectly relate to saving Betsy.The thing I find most interesting is the emergence of a unique and compelling purpose within this team. It enables them to innovate in all areas: people, process, tools, software delivery.  To sum it up in the words of Paul Opryszek

Betsy was born in rustic King county in mid 2008. Her dairy farmer was Paul Opryszek who was fortuitously struck by a bolt of Agile lightening that restored Vision as well as Belief in Truth, Beauty, and Resource Allocation sanity

1 Comment

  1. Pete

    A nice analogy for agile team composition! I found your site via a link from one of our own threads ( which also discusses cross functional teams. I am about to add a link to this thread as it may interest our readers.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You May Also Like

Insights From My Journey into Scrum

Insights From My Journey into Scrum

Reflections on 3 Years as a "Scrum" Master and Scrum Master I came to be a Scrum Master after burning out on my career as a Technical Writer. Luckily, my boss at the time approached me with a new opportunity.  “We do Scrum,” he said, “and we need a Scrum Master.” I...

Dance Of The Scrum Master – Ask Don’t Tell

Dance Of The Scrum Master – Ask Don’t Tell

I recently attended an Advanced Scrum Master Certification course facilitated by Evolve Agility. I have been working on scrum teams for about fourteen years. Over the years I have been a development team member, scrum master, product owner and scrum coach. I consider...

Healthy Product Backlogs

Healthy Product Backlogs

Healthy Product Backlog: Customer immediately understands every item in the product backlog. These are commonly useful good practices to get your product backlog in healthy state. Try these, your mileage may vary: (1)  Customer goal oriented product backlog items....