The Chivalrous Team Member:

In seeking to improve how we develop software, we continually inspect and adapt. While thinking recently about the characteristics of the ideal scrum team member, we found similarities between the best-performing software teams of today and the Knights of the Round Table. Robert Goulet, as Lancelot in ye olde movie Camelot, sang:

“A knight of the Table Round should be invincible,
Succeed where a less fantastic man would fail.
Climb a wall no one else can climb,
Cleave a dragon in record time,
Swim a moat in a coat of heavy iron mail.
No matter the pain, he ought to be unwinceable.
Impossible deeds should be his daily fare.”

While we do not think our team members need to be able to cleave a dragon in record time and most would look strange in a coat of heavy iron mail, we do think the ancient code of chivalry serves as an excellent code of conduct for team members on today’s complex software projects. Our demons are no longer dragons, fair maidens in distress, or a wicked cousin (next in line for the throne!). Yet, certainly, given the schedules that many are asked to meet, impossible deeds are often our daily fare.

Hang on—before you think we’re crazy or that we’ve spent too much time watching Robin Hood: Men in Tights, allow us a moment to plead our case. Ancient knights were chosen as much for their personal traits as for their strength and agility. We suspect you hire team members as much for their personal traits as for their technical knowledge and experience. We prefer team members who are dependable, communicate well, are flexible in their preference for technologies or tools, generous in sharing their time with others, and loyal to the team are preferable. In fact, many of the sought-after attributes for knighthood in “auld times” are still desirable in team members today.

It was with this thought in mind that we mounted our trusty steeds (Firefox) and visited our magical search engine, Merlin (aka Google), on a quest to discover the exact code of chivalry by which ancient knights lived. What we found was that there was no single ancient code—ancient knights and authors described knightly virtues differently. However, the various ancient codes were combined and updated into a modern code of chivalry in 1997 by Brian Price, an expert in medieval history.

In Price’s modern rendering of the ancient code we believe we’ve found the Holy Grail of desirable attributes for today’s chivalrous scrum team members. We start each of the following sections with one of the ten virtues described in Price’s modern code of chivalry.

Scrum Team Member And Prowess

To seek excellence in all endeavors expected of a knight, martial and otherwise, seeking strength to be used in the service of justice, rather than in personal aggrandizement.

We’d certainly like to work with team members who seek excellence in all endeavors. Before Mike began his career as a consultant, his main criterion in deciding whether to join a company or team was whether there were individuals on that team from whom he could learn. Not only does being around others who pursue excellence in their endeavors provide learning opportunities but it also pushes each of us to be our best. If we know that our team’s DBA is writing sloppy code in the database because he doesn’t think this product will be around for the long term, then we, too, are more likely to write sloppy code.

Of course, if excellence is sought solely for the sake of personal gain, then it does not benefit the team. The ideal scrum team member is one who seeks excellence because it helps the team as a whole.

Prowess extends to resolving problems that are “not mine.” This should be done not for fame but for the betterment of the product. Martin has observed that often when a team starts to work together more collaboratively, some of the stronger subject matter experts struggle to become part of the team. Strong subject matter experts are used to acquiring fame for resolving difficult problems. As the scrum team works collaboratively to solve problems, individual fame evaporates and is instead shared among team members. For some this is a difficult transition.

Scrum Team Member And Justice

Seek always the path of “right,” unencumbered by bias or personal interest. Recognize that the sword of justice can be a terrible thing, so it must be tempered by humanity and mercy. If the “right” you see agrees with others, and you seek it out without bending to the temptation for expediency, then you will earn renown beyond measure.

Ruby on Rails is currently a hot technology, so Mike wasn’t surprised to see it in use at one of his client sites. What did surprise him was that this particular client was using Ruby—it had used and was still using Java for all its other development work. A number of Java systems built over the past five years, new projects beginning in Java, and one new project in Ruby on Rails seemed an odd combination. After a bit of questioning it became apparent why the new project had been started in Ruby on Rails, and the reason is one that underlies too many technology decisions—the project was being done in Rails because the two senior developers on that project wanted to add Rails experience to their résumés. Any doubts about this evaporated six months after the project started when one of the senior programmers left for a shiny new Rails job.

Someone who always seeks the right path for a project, unencumbered by personal interests or bias, is definitely someone we would want as a team member.

Scrum Team Member And Loyalty

Be known for unwavering commitment to the people and ideals you choose to live by. There are many places where compromise is expected; loyalty is not amongst them.

A scrum team member displays loyalty in a number of ways. You need to believe in the principles and goals your team has agreed to follow. If your team has chosen to do a daily build and to never go home while the build is broken, you must be loyal to this precept. You must be loyal to your fellow scrum team members even in times of stress or conflict. A team can only be self-organizing when each team member freely gives information and assistance to other team members without a need for personal gain. True belief and loyalty in the development ideals you choose to live by must never be waived.

Loyalty to our customers and stakeholders is also important. As developers we give the business control over priorities. As team members we must stay loyal to these objectives and not think we know better or make our own judgment on what the business “really needs.”

Scrum Team Member And Courage

Being a knight often means choosing the more difficult path, the personally expensive one. Be prepared to make personal sacrifices in service of the precepts and people you value. At the same time, a knight should seek wisdom to see that stupidity and courage are cousins. Courage also means taking the side of truth in all matters, rather than seeking the expedient lie. Seek the truth whenever possible, but remember to temper justice with mercy, or the pure truth can bring grief.

It can sometimes be difficult for a team member to be the bearer of bad news. No one wants to admit at a daily stand up that he needs assistance. Martin recalls the first time he needed to seek help from his team:

“I had just been exposed to object oriented programming after a decade of procedural programming on mainframes. I was struggling and needed help. However, a feeling of guilt and failure came over me in the daily stand up, discouraging me from expressing my problem to the scrum team. I tried to avoid asking with delay tactics and some dodgy procedural programming hacks. Eventually, when I did ask, I was pleasantly surprised with the reactions of my team members. People congratulated me for saving days on the project by expressing my problem quickly so that a resolution could be found and acted on by the team instead of burning money in a solo effort that would most likely have ended in failure.”

It takes courage to tell your teammates you need help. Such courage should be encouraged, because by speaking openly you are seeking the best results for the team.

Courage is also required when speaking with clients or management. For too long we have deceived our clients by saying progress was steady, when in truth deliverables could not be met on time or on budget. In the past we continued blindly, hoping to “catch up” but inevitably failing our clients. The courage in giving a true and honest reflection of progress (velocity) will be rewarded as you are supplying the client with the ability to change perception, scope, and so on in enough time to achieve success.

Scrum Team Member And Faith

A knight must have faith in his beliefs, for faith roots him and gives hope against the despair that human failings create.

Every team member needs to have faith in the scope accepted into an iteration and in the goals and development principles of the agile methodology in general. Expressing dissatisfaction after the planning meeting and continually attempting to railroad the iteration via a series of interruptions will have a very negative influence on achieving the goals set. Faith in all decisions made in iteration planning is needed, which is why it is so important to seek consensus. Doubts should be noted and revisited in the retrospective where success will be inspected and, based on team dialogue, adaptations may be required going forward.

Agile can be effectively implemented only when all scrum team members have complete belief in the processes. Martin found himself in a difficult situation when he left a first iteration planning meeting with a team member clearly not happy about using agile techniques. This individual predicted failure of the agile process and was quite public in voicing that opinion.

The iteration was railroaded and a lot of Martin’s time was spent doing damage control, resolving the rifts that this vocal negativity wrought within the organization. This experience underscores not only the importance of consensus when a scrum team decides on its beliefs but also the strength of faith a team needs to have in its process when that process is challenged.

Scrum Team Member And Nobility

Seek great stature of character by holding to the virtues and duties of a knight, realizing that though the ideals cannot be reached, the quality of striving towards them ennobles the spirit, growing the character from dust towards the heavens. Nobility also has the tendency to influence others, offering a compelling example of what can be done in the service of rightness.

Teams usually take their first steps toward agility in one of two ways: They focus on learning to work in short, timeboxed iterations, or they focus on learning a couple of new technical practices, such as pair programming, emphasizing automated unit testing, or doing test-driven development. These initial steps often lead to great results that should serve as the basis for becoming more agile. Unfortunately, we see too many teams stop after this first success. They forget that part of being agile is continuously improving. Scrum teams, like ancient knights, should strive to reach ideals—perfect, bug-free code every time—even though they know they can never succeed.

Teams must remain noble when trying to influence others in adopting agile. Forceful exertion of beliefs does not work. Self-awareness and empathy are the skills we must master. In order to influence others, you must begin by understanding how people feel, their perspectives on the topic, and what factors are influencing their decisions. While empathizing, we must strive not to preach, bully, nag, or belabor a point. Influencing others occurs through a bond of respect to one another, a sharing of goals, and a strong sense of conviction toward achieving those goals. Attaining these skills requires constant effort.

Scrum Team Member And Largesse

Be generous in so far as your resources allow; largesse used in this way counters gluttony. It also makes the path of mercy easier to discern when a difficult decision of justice is required.

Who hasn’t worked with the colleague who gave freely of his or her time, patiently answering our questions, and showing how things should be done? This type of mentor—whether senior to us in the organization or not—can have tremendous influence. Not only do we learn skills from such a colleague but we also learn the value of mentoring and repay that kindness by mentoring others ourselves.

Sadly, many of us have also worked with the colleague who refused to share his time or expertise—the gruff coworker who clings tightly to his knowledge of how to change the transaction date on processed data records, following his unstated rule that unshared knowledge leads to job security.

Which of these individuals did you prefer working with? How would you like your coworkers to think of you? Be generous as far as your knowledge and experience allow.

Scrum Team Member And Defense

The ideal knight was sworn by oath to defend his liege lord and those who depended upon him. Seek always to defend your nation, your family, and those to whom you believe worthy of loyalty.

Though ancient knights may have willingly given their lives to defend their liege lords, we’re unwilling to suggest that modern-day software chivalry calls for a scrum team member to be willing to die in defense of his CEO. In this modern age team members instead need to defend their applications vigilantly. Applications are frequently under siege from decaying code, schedule pressure that leads to sloppiness, and budget constraints. Rather than fight these modern-day dragons with lances, broadswords, and axes, today’s chivalrous team member relies on automated testing, test-driven development, refactoring, working at a sustainable pace, and other agile weapons.

The products we build can in turn be used as weapons in defense of our users. When developing software, spare a thought for the end-users and how effective they can be at their jobs. What is the end result of the infamous suggestion of a “manual work around?” To achieve an effective working relationship with users, our perspectives and relationships with them must change.

Scrum Team Member And Humility

Value first the contributions of others; do not boast of your own accomplishments, let others do this for you. Tell the deeds of others before your own, according them the renown rightfully earned through virtuous deeds. In this way the office of knighthood is well done and glorified, helping not only the gentle spoken of but also all who call themselves knights.

Humility is a very strong element in any transition to agile. An effective team with a strong collaborative style does not have room for large egos. Team members seek satisfaction by experiencing how their achievements (however small) can combine into a continually improving product. Chivalrous team members frequently ask, “How has my accomplishment today enabled other members of my team to complete related tasks?” Regular releases to users provide another sense of satisfaction when users are able to do some business function they couldn’t previously do.

Scrum Team Member And Franchise

Seek to emulate everything I have spoken of as sincerely as possible, not for the reason of personal gain but because it is right. Do not restrict your exploration to a small world, but seek to infuse every aspect of your life with these qualities. Should you succeed in even a tiny measure then you will be well remembered for your quality and virtue.

The benefits of adhering to the principles underlying agile software development can be applied in other walks of life. We are aware of or have used the principles of transparency, short timeboxes, measurable progress, rapid feedback, and increased communication in planning a wedding, renovating a restaurant, running a sports club, and managing a child’s school work.

Whether you have dragons to cleave, maidens to rescue, or simply deadlines and budgets to meet, working daily in ways that exhibit the ten knightly virtues is sure to help your scrum team accomplish these once-impossible deeds.