Dhaval Panchal’s - Agile Blog

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. Hear 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

Experience Betsy, culture, emergence, purpose, scrum, self-organization, team

Def: Velocity is the amount of product backlog that a team can fully implement through product owner acceptance with in a given sprint.

Tools & Artifacts future, productivity, release, team, velocity

A few months ago, I was facilitating sprint retrospective for a multi-cultural team that had members of different national origins (UK, South Africa, Angola and United States). We started gathering information regarding their first sprint. I realized that this team was struggling to simply get along! We took a step back and created a focus for our retrospective. We elicited the following goal for our retrospective:

During the course of this retrospective, team members discussed how they can improve trust, respect & communication within the team. The fact that the team had individuals from different cultural background was not missed. The crowning moment during the retrospective came when one of the team members said:

“In my culture, we have to be friends, for me to do good work. In the western culture, I have to do good work, for us to be friends.”

These words have echoed in my head for a very long time. His insight has been a great learning experience for me. I have learned to acknowledge and appreciate differences in individual values. But what are these values?

Exercise: Sharing Values

Step I: Identify a pair (optional)

Ask your team members to identify someone within the team that they are comfortable with. Ensure all pairs have been identified and if there are odd numbers of people, the facilitator can pair with the lone individual. Ensure that every one has some index cards and a sharpie.

Step II: I don’t like it …

On a single index card, ask each team member to complete this statement:

“I don’t like it when someone/people …… “

Encourage each team member to write down 2-5 such statements on separate index cards.

I have found that it is easier for us to identify behaviors that we don’t like, especially when we have been at the receiving end.

Step III: Exchange Cards

After everyone is done writing, exchange all your cards with your partner.

Variation: If you have opted not to do Step I, then place all these cards in the basket/hat. Now randomly pick cards from the Basket/Hat. If you get a card that is yours, then place it back into the bucket/hat. Ensure all cards have been distributed.

Step IV: I like it …

On the back of each index card, write down a statement that will counter your partners “I don’t like it …” statement with

“I like it when someone/people….”

You will be amazed how your team member’s insight into your hot-button issue helps you recognize behavior that you will truly appreciate!

Step V: Share Values

Go around the table where each team member reads aloud a statement that begins with “I like it when …”. Take turns reading one statement per team member at a time until all statements are exhausted.

These are your team’s value statements. These statements provide a simple list of positive behaviors that are currently valued in your team.

Caution: As a facilitator/scrummaster refrain from vocalizing these statements yourself. I believe it is very important for everyone in the team to hear these positive behavioral statements from their peers.

Step VI: Team Values Chart

On a Big Visible Chart only capture statements, that begin with “I like it when …”. Radiate this information in your team area for the benefit of your team members and others who interact with your team.

This exercise takes less than 30 minutes to do. Try this exercise again after a couple of months; see how far your team’s values have evolved. As a manager/scrummaster/team member, if you feel tempted to dictate good behaviors to your team, take a deep breath and try this exercise with them. Maybe, just maybe, your team will self-organize to correct its own behavior.

ps: Suggest destroying index cards that were used for this exercise.

Facilitation Exercises culture, exercise, scrum, scrummaster, self-organization, team, value