Agile Careers


Jim ("Cope") Coplien is an old C++ shark who now integrates the technological and human sides of the software business as an author, coach, trainer, and executive consultant. He is one of the founders of the software pattern discipline, and his organizational patterns work is one of the foundations of both Scrum and XP. He currently works for Gertrud & Cope, is based in Denmark, and is a partner in the Scrum Foundation. He has authored or co-authored many books, including the recently released Wiley title, Lean Architecture for Agile Software Development. When he grows up, he wants to be an anthropologist. 

Log in to register a comment.

Subscribe here.

Blogs Blogs

Entries with tag scrum.

Tell Me What to Do, Daddy

A few weeks ago I was invited to comment on a checklist for Scrum Product Owners. The list wasn’t obviously wrong; it had many of the elements that anyone would enumerate after a casual two-hour introduction to Scrum. It’s not the first such checklist I’ve seen. This one in particular made me uncomfortable at the level of principles that are crucial for what matter in life and career. As such, it helped me tie together a wide range of topics I’ve written about earlier in this forum, and I’d like to share my reflections here.

I wrote earlier about the theologian Carse and the way he distinguishes between finite and infinite games. A job is like a finite game with a finite set of rules, and has a short-term goal. An infinite game is open-ended both in its rules and the valuation of its ongoing outcomes. Carse’s perspective is a great metaphor for job versus vocation.

A career starts as a job. A job offers new challenges, no matter what your educational background or experience, and the adjustment starts with delineated changes in behavior. For such jobs I’m not against checklists. Written media can provide cues and reminders of the rote of our learning. A written medium like a list is a starting point to grow knowledge, and knowledge can be a foundation for learning.

Learning takes place by growing through plateaus. In Aikido we talk about the shu, ha, and ri levels of learning. Shu is about blind obedience — well-suited to checklists and rules. You learn exactly how to do shomenuchi (head strike) by imitating sensei. But even in shu, the key is intentional practice: repeating the action hundreds of times. The next level, ha, means “to break.” You break the rules of one sensei in favor of the superiority of those from another in a given context.  At ri, you break with your school and you are sensei. Shu is about what you do. Ha is about what you are in the moment. Ri is about what you are becoming.

Rules can be conveyed as audits; attitudes, less so. Great tennis players can’t write down the mentality that makes them great. Maybe stories work; it must be learned, but cannot be taught.

The checklist angered me for two reasons. First, it was off the mark. If it had been a list about knowledge, or about a task-driven job like product management, such oversights are easily forgiven. But, second, it took the broad attitudinal role and reduced it to a checklist process. It’s like defining a priest in terms of the rituals he or she performs instead of the love, piety, and humanity germane to the role. My anger left me sad, because it became clear that this person will never see that he would not be the right person to write such a list even if it were about lists. He had reduced the role of Product Owner to the lowest rudiments of the mechanics of a product manager.

Being a Product Owner is about long-term value, which is focused outward and, in a vulgar sense, on the market but, in a human sense, on the community and on humanity. You find this in the sense of harmony present in the Japanese roots of Scrum. The list was not obviously wrong in its individual elements. But Carse tells us that playing an infinite game as though it were a finite game is the very definition of evil. In the end, this checklist was no less so.


Agile claims to be about embracing change. While career used to be about moving up the ladder, like kings amassing gold and possessions corresponding to their power, today’s agile employee should perhaps ponder a more monastic posture of unattachedness and service.

Yesterday my family was rudely awakened to the untimely death of a dear friend, and it is those thoughts that lead me into this topic today. She had a great career, but her gifts were cut short at a young age. Not all careers lead to such a dramatic end, but none of us should assume the permanence of our position, or even of a continued upward direction.

Tibetan Buddhism focuses on the impermanence of all things. Maturing in life is about letting go so that at the end of life, one has a lean and tidy house and few attachments. If you are encumbered with many belongings at death it leaves a mess for someone else to clean up. Too many of us leave ourselves at peace with the knowledge that it won’t be our problem in our lifetime to put things in order, and we self-unconsciously shift the responsibility onto our colleagues, our partners, and our children. A testament doesn’t solve it, either: it can never cover everything — certainly not the unknowable, detailed attachments to trinkets that some loved one might silently carry — and there is the inevitable jealously that can arise between heirs feeling disempowered by an inflexible, final word.

This is where Lean complements agile. A Lean career doesn’t stand on once great artefacts such as a single landmark book or a lofty title once held in a powerful corporation. Today’s writing is transient, and position is fragile.

Daily attachment to artifacts or positions is fertile ground for this same inflexibility, and this is why it’s important to view agility as an ongoing process of letting go. Scrum encourages people to move around the code, and while there may be some area in which you excel and some code for which you might be the best maintainer, it’s important to let go of that position, defer to others, and explore other system areas. Scrum allows no internal structuring of the development team, either by roles or by sub-teams: such structures are the molasses of change. You can’t stand on your role: your role now is temporary, and may change tomorrow.

The same is true in the larger vista of career. The most recent data from the Bureau of Labor and Statistics point out that people hop jobs on the average once every 4.4 years. Though I am of an earlier generation I’ve moved from computer operator, to developer, to ethnographic researcher, to higher education, through EDA, and into organizational consulting.

Perhaps the pursuit of permanence is tied to the quest for security in prosperous cultures, where prosperity is perceived as being possible or even a birthright: the American dream. Perhaps such cultures create a fear of not belonging to the endowed, and that fear drives us to seek external, concrete tokens of worth. Challenge yourself to put that aside and contemplate a monastic existence which values the day’s contemplations and ideas, and the lifting of a community, above individual excellence.

Small changes in career and stature are not change in the honorable sense of the term, but simply responding to variance. When change happens, check for a bigger picture. Nature may be trying to tell you something. If you find that she is whispering in your ear, take the opportunity to seize her hand, to embrace change, and to consider re-planning.


Andrea Tomasini’s mail byline has long been, “Agile isn’t something you do; it’s something you are.” It’s a tidily profound statement. Agile is about what you do in the moment; lean is about what you are. Andrea’s saw points more in a lean direction than an agile direction.

Where are you on your corporate merit ladder? Stack ranking is the darling of American culture and one of its most poisonous exports. It has taught engineers to establish a turf of some niveau, often heralded by a suitable title.

Such scales tend to have no definitive top. Barry Boehm notes that individual software skills vary by two orders of magnitude. The scale is logarithmic, and the top is difficult to delineate. For years the four-minute mile stood as an absolute, as did the 30 Kelvin limit for superconductivity. The limits humanity set for itself seem always to fall, and that is perhaps a deep aspect of what makes us human. What we do in any moment is for that moment, and is passing. What we are carries with it the potential to excel in the moment — and maybe more. But that’s a matter of effectively employing our faculties.

It’s less about what what you do than what you are and, beyond that, more about becoming than being. The difference between what you are and what you can become is a difference of statics and dynamics. “Doing your best” on a job is about what you are. My friend Jens Østergaard is a good and prolific Scrum trainer who understands that the future holds uncertainty. Both of us teach people to live each day of our projects expecting occasional failure (see: There is no Failure, only Feedback). If you fail, you can take comfort in knowing that you did your best.

Did your best is always in the context of what knowledge and resources were available to you at the time. Experience is sometimes the best teacher. It gives you the option to grow, and if you’re growing, what you will be tomorrow won’t be what you are today. The delta is about becoming.

Kaizen mind focuses more on this process of becoming than on what one is at any given time or even on the succession of hopefully ever-improving accomplishment or performance levels. The differences are subtle. The first focuses on results, and that phrase “focus on results” probably rings loud in the ears of those whose corporate cultures take it as a rallying cry. In a complex world, results are always transient in the moment.

Rather than focusing on results, it’s about focusing on the improvement process itself. Consider one engineer who focuses on improving her design, ever reducing the power needs of some system component. Meanwhile, another engineer focuses on making sure the feedback loops are in place and finds wisdom in many counselors instead of hanging her hopes on the insights that the current product generation yields up or that one can glean from a history of such data. The former is Pavlovian: a facility we can ascribe to dogs and even to earthworms. The latter is perhaps uniquely human, and may lie at the foundation of happiness in life.

“Becoming” is a word that Nonaka-sensei uses often. The grandfather of Scrum, he is steeped in the Japanese process frameworks that have inspired much of the modern world of complex development. He knows that focusing on the process will yield value; staring results too directly in the face leads to performance myopia.

Do-be-become. Do well, just be yourself, and continuously challenge yourself.

Showing 3 results.