Build Your Career: Agile Careers 


Agile Careers

"Cope" Coplien

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 Wiley title, Lean Architecture for Agile Software Development. When he grows up, he wants to be an anthropologist.

Log in to register a comment. We encourage lively debate, but reserve the right to moderate comments. Contact buildyourcareer@computer.org for questions.

Subscribe here.

Blogs (Blog) Blogs (Blog)

Entries with tag engineer stereotype.

Sacred Stories

As engineers we sometimes think of ourselves as objective applied scientists. Yet IEEE defines engineering as “promoting the development and application of electrotechnology and allied sciences for the benefit of humanity, the advancement of the profession, and the well-being of our members.” Technology is the means; the end is society, culture, and people. Engineering is a culture, and IEEE is a society that represents electrical engineering’s professional face to the world: a society embedded in that culture.

Every culture has its sacred stories: literature that underlies social progress. Our culture has entrusted the keeping of its written record to the IEEE and ACM. These are that society’s sacred, eternal foundations, capturing hard-won insights and enabling the spread of knowledge and innovation. So priceless are these that the cost of admission to this library is high: approval by reviewers, distinguished series editors, and by program committees and their chairs.

Nature News announced on 24 February that IEEE has removed over 100 published papers after discovering “that every single one is nothing more than fancy-sounding gibberish.” (http://www.nature.com/news/publishers-withdraw-more-than-120-gibberish-papers-1.14763). IEEE was aware of the general problem back in 2012 and removed some papers then; two weeks ago, they removed more based on input from Cyril Labbé at Fourier University in Grenoble.

It’s bad enough that these supposed engineering truths were removed: it’s tantamount to revoking the Ten Commandments.  It’s easy to blame those who scammed the system, but it’s unlikely they were seeking publication accolades. They have in fact provided a service in showing a weakness in the system.

The most worrisome issue isn’t that bogus papers made it into the IEEE canon, but rather that the same process that admits meaningless papers can just as well accept ungrounded or misleading papers by everyday authors. And the IEEE isn’t alone. The 2011 ACM SPLASH conference published a workshop paper about work with which I was familiar, with a claim of formally proven results. I knew that no such proof was possible and published a workshop paper at the same conference in 2012 documenting a concrete counter-example to their “proof”.

Academic publication processes are unfortunately plagued by sloppiness, over-eagerness, opportunism, politics, and returns of mutual favors. My colleague Doug McIlroy (the inventor of UNIX® pipes) advised me in 1991:

It was pointed out in my NRC committee on whither computer science that conference proceedings, even the prestige ones like STOC, FOCS, and SIGGRAPH, deal in incomplete papers quickly refereed.  Many illustrious computer scientists have given summaries of results in proceedings papers and then never fleshed them out; more than once it has happened that the result is wrong, at least in detail. Thus a surprising theorem announced in proceedings should be regarded with skepticism.  If you regard your work as of more than transient value, and hope that others will too, you will go the extra mile for archival publication. Conference proceedings keep the pot boiling on the stove; the archival literature provides the floor for the stove to stand on.

The Lean mantra is: Have the right process and you’ll build the right product. IEEE reviewed this problem once in 2012 and “refined our processes to prevent papers not meeting our standards from being published in the future.” Process improvement remains a never-ending quest.

Another Lean mantra is: Go down to the Gemba. Even if only for reasons of changed context, you owe it to yourself to validate crucial technical foundations before moving forward on them. That it appears in writing doesn’t make it true.

Ponder the Great Questions

Engineers love solving problems. Unlike scientists, engineers often don’t get to choose what problems to solve. We’re told: Build this circuit! Design this bridge!

If you could define the questions, what would they be?

Not every innovation you come up with must be worthy of a Nobel Prize. A career-minded engineer can craft a vision for a given project, a given employment situation, or for one’s entire career, and then strive to shape individual assignments to move closer to that goal. A balanced career comprises an interleaving of such assignments because it’s true both that concrete short-term results inform long-term strategy, and that models that are informed by the voice of broad experience help set the compass points for near-term endeavors.

Goals that reflect the great questions of our time take many shapes and forms. Some lie in the realm of research: to make quantum computing practical, to create economic sources of hydrogen for fuel cell cars, or to derive programs from natural language. Others are technical, like breaking boundaries of chip densities or finding heuristics that shorten data lookup times. And some are social, ranging from laying out your department’s new organizational structure to shaping the moral fabric of a group, enterprise, or industry.

In this age of Internet time scales most of us feel a daily tug towards the bottom line. Instead of worrying about how much your next raise will be, worry about which country you will next target — that your business can raise the quality of life there. Edwin Land (the Polaroid-Land camera guy) reminds us: “The bottom line is in heaven!” Alan Kay remarks that instead of worrying about measuring answers right/test or tests-passed/year, we should be measuring “Sistine-Chapel-Ceilings/lifetime.” And we know that the former doesn’t correlate with the latter (see Certification).

Sometimes small answers contribute to resolving great questions, and we often have to settle for interim deliverables instead of the home run. If your day-to-day tasks are anchored in a vision, work will not only be more meaningful but you’ll be less likely to wander in the wrong direction. Understanding the broad direction can cover a multitude of lower-level misunderstandings, and the broad direction usually wins out even when it contradicts the specifications that come down through a noisy corporate process. Think globally, and act locally.

When I take a consulting engagement with a company, it always must address a great question. I work with firms who can look beyond themselves to their broader role in humanity, not only now, but for years to come.  It doesn’t have to be a question that humankind recognizes as grand, but it must be something that I myself believe to be strategically  important to humankind.

Many of these great questions face engineering today. We are both a destructive and healing force in biological ecosystems, and each one of us is accountable for both the tearing down and building up that happen at engineering’s hands. Grady Booch reminds us: “Just think about it: there is practically nothing you see or do in your daily life that is NOT created, supported, delivered or impacted by computing.” That goes for both the good and bad, and we’re at the root of both.

Pondering the great questions takes time and, for most people, that means getting away for a while. Get into an environment where you can avoid the Tyranny of the Urgent. Take a Google Friday once a week, a retreat once every few months, and a sabbatical every few years.

Policy and Mechanism

My friends Dennis and Tom taught me everything I know. One of Dennis‘ favourite themes was the need to separate policy from mechanism. It’s a broad principle applicable to many systems.

The dominant policies in most systems serve business goals, and the mechanisms of technology should serve this greater purpose. The goals aren’t to adhere to the tenets of three-layer architectures, to coupling and cohesion, nor to the Laws of Demeter, but rather to realise end user value and system maintainability. Good design harmonizes policy and mechanism to support harmony across borders of all sorts in the business ecosystems where countless mechanisms interact seamlessly.

Agile embodies one such set of mechanisms. Though this column is called “Agile careers,” my work these days relates more closely to the Toyota Production System (TPS), commonly confounded with “Lean”. Both agile and TPS aim to increase stakeholder value. Agile’s prime mechanism is responsiveness; to this, TPS adds planning. TPS and agile differ in many other mechanisms but they are not entirely incompatible: Scrum ecumenically combines mechanisms from both.

Going further afield, waterfall isn’t wrong; it just fits a different context than we find suitable to either TPS or agile. It may be a rare context where we know requirements up front, but waterfall isn’t fundamentally evil as most agilists would make it out to be. It’s just different.

We tend to harbor beliefs about our design methods with little basis either in science or reality. Our ignorance blinds us to contexts beyond our own, and our myopia to wrongly claim the universality for methods that in fact work only in our own context. We agilists are among the worst of zealots: first in our collective ignorance, and second in our almost arbitrary adherence to fashion. Such adherence is too often blind, lacking understanding of the whys.

In this holiday season it’s important to separate policy from mechanism. It’s a season when the world celebrates the winter solstice, once viewed as a manifestation of the powers greater than us (which stands true but less mysterious than in yesteryear) that brings the wheel of climate around to a new season of weather. The grandeur of the event causes us to confound it with religion, and most celebrations of the season have religious connections: Hannukah (though it was a bit early this year), Christmas and Western New Year, Ed-al-Adha, Diwali, and a few more.

More broadly, religions use the season to showcase the human policy of “peace on Earth, good will to men,” but also celebrate their own mechanisms. The Law in the inspired written word is the primary mechanism for much of Judaism; it is the same for Christians, except the law regenerates as a child. Along with these, Islam emphasizes the mechanisms of devotion and service; in Buddhism, it is self-awareness of how our own actions cause suffering.

All of these all share the same unifying policy; the mechanisms have value in their own right and are practical and local. We too often overlook the bigger picture and wallow in our mechanisms. These lapses are borne out of human insecurity and the need to feel that we control life, rather than aspiring to destiny or the higher calling that transcends mortality. 

This holiday season, look beyond your mechanisms to celebrate the winter solstice with fellow world citizens. As in great design, submission to purpose is a matter of humility and gratitude. Find mechanisms that suit your culture and context and by all means celebrate those, too. Just don’t spoil the neighbor’s party with the noise of your own.

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.

Feelings are Facts

This morning I had to decide between baking the last apple pie of the season or to focus on a an ACM paper that might, in the long term, steer the industry. The ACM paper is relevant to my business, career and profession and it’s less obvious that baking the pie is relevant to any of those. I’m sure no one in my constellation would be offended if I were to forego the pie and dutifully edit the paper. My head tugged one way, but my heart tugged the other. It’s not the first time it’s happened. And I’m sure you find the situation familiar yourself.

Freud said that we should agonize about trivial decisions but make life decisions from the gut. We’re advised to flip a coin, ostensibly to let fate decide a difficult issue for us, but more insightfully to gauge our reaction to the result after having intellectualized a tentative direction. Jerry Weinberg says: Feelings are facts.

As a “whole person,” I actually don’t comprise parts to which classes of decisions have been relegated. I’m sure that what I ascribed to my heart above actually plays out in the cerebral cortex. We tend to let feelings play second fiddle because of our profession, because of our self-image, or because of what society has taught us. Reality is probably less complicated.

Any corporate executive who regularly used such an approach and who openly admits so, and who advocates subordinates to do the same, would be viewed as “shooting from the hip.” It is likely that he or she would not be able to hold a position of responsibility long, in spite of repeated good results.

On one hand, stakeholders do want to understand the basis for our decisions, and “I feel good about it” usually isn’t enough. That seems to be a sad casualty of the context we live in, and I’d love to hear from you how to deal deal with such feedback.

On the other hand, an over-rationalized value proposition can lead to stark conservatism or just plain silliness. George Bernard Shaw reminds us that “all progress depends on the unreasonable man.” The military mind is often calculating and stands either on metrics or on the campaign styles of history. Robert McNamara ran the Vietnam war by body count, sometimes as though he were “a desk officer” (Herring, “The Wrong Kind of Loyalty — McNamara’s Apology for Vietnam,” Foreign Affairs, May/June 1995). Though he never relented on the metrics, his broader war management framework haunted him until his death in 1993. His contrition about this outlook and his open apology allowed him to die an honorable man. “The processes used to arrive at the total strategy are typically fragmented, evolutionary, and largely intuitive.” (James Quinn, Strategic Change: Logical Incrementalism, 1978)

AT&T once proved to itself that analog telecommunications was more cost-effective than digital. It felt right to go to  digital, but the numbers didn’t bear it out. Northern Telecom’s DMS-100 switching system caught them with their pants down, and they spent years playing catch-up.

Don’t discount that internal voice that distracts you from your “official” mission. The conscience sometimes speaks with a soft voice. It takes sensitivity to discern between a wise voice and the overspringshandling I contemplated in an earlier installment here. Methodical doubt can help your exploration.

A deep urge led me to put aside my task of the moment and write this article. But I’ve got to go now — the timer has gone off and it’s time to rescue my pie from the oven.

Methodical Doubt

All professionals recognize arbitrary truths that direct their day-to-day work. Such norms of respect for knowledge are keystones of culture. They become the unspoken and assumed backdrop against which professional discourse takes place. We first pick up these bits of authority through our education and find them reinforced in our interactions with those colleagues who came through the same upbringing.

Engineers are luckier than most because, at least for the simple stuff, we cling to the edge of the sciences. We put our faith in indisputable truth. E = IR, F=MA. The fist problem is that, within the span of a career, even the truths are disputable. Until 1986 we knew that superconductivity couldn’t exist above 30 degrees Kelvin; the 1987 Nobel Prize in Physics went to those who established superconductivity at 35 degrees Kelvin. The amount of knowledge doubles in science about every 10 years. But the larger problem is that many claims we hold as truths aren’t truths at all.

Engineering is often a hammer used to reinforce a timeless “truth.” The engineering label gives any claim a sheen of credibility, but it is in fact the self-reinforcing culture of like thinkers that gives these “truths" power.

The old days of software development were grounded in a belief that discipline could generate perfect up-front requirements — a belief that perhaps emerged from the hope that such reasoning could eventually be fully automated, but that good human effort was an adequate substitute in the mean time. Methodology — another one of the truths that was a product of that culture — was held to be enough to achieve success. If we ever failed to deliver, we blamed ourselves and created a notion called a “post-morten” to discover where we had failed to follow the methodology. No one dared question the methodology itself.

As engineers, we are prone to follow method. Have you ever been working on a project and, faced with a design decision, found yourself falling back on one of the rules you were taught, in spite of the fact that you had more than an inkling that the current wisdom might be unwise?

Few truths are absolute; it is in fact unlikely that there is any single static truth in any endeavor. Truth is a process. Strongly typed programming languages are not always good, and weak typing sometimes has its advantages. Context is everything, and experimentation and good dialog are its handmaidens. The biggest problem with the dogmatic engineering mindset, rooted in the supposed truth of the sciences, is that they are context free. Most interesting complex problems of the modern world are highly contextualized. There is a two-edged sword here, as the common wisdom is diluted as much by fads as by myths. Again: experimentation and dialog must prevail.

Progress in day-to-day practice should enjoy more immediacy than Nobel recognition allows. And while peer review is important, common sense and collegiality in your workplace and professional societies can go a long way, particularly when coupled with methodical doubt. The next time your intuition runs up against the standards of truth of your discipline, talk up your idea a bit. Experiment and work against the grain a bit. You don’t have to be a genius to realize these breakthroughs. Hundreds of engineers recognize them every day but, repressed by the industry myths and the leverage they exert through peer pressure, retreat from learning to the misguided rote of alchemy. Great invention happens humbly every day. Don’t let the disproportionate recognition of a select few inventions discourage progress.

Transience

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.

Are you running from, or running to?

Most of us who view ourselves as successful draw on an inner source of either adrenaline or endorphins that accompany the excitement of new life directions. They move us to action that effects change. People who claim to inhabit the higher planes of professional existence seek out, or at least are able to recognize, the force the moves them to these levels of energy. We have phrases like “things are just clicking” or “flow” or (how 1960s) “in the groove” at work. Like a runner, we’re on runners’ high, fueled by that adrenaline and those endorphins.

However, this rush can sometimes be an unhealthy placebo or diversion that we use just to distract ourselves from our deeper fears. The philosopher Pascal in fact admonished us that our careers and hobbies are just a way to keep us from facing the true plight of humanity, lost in a universe incomprehensible at human scale. In your career sprint are you running toward the goal? toward anything? Or are you running from something? It’s easy to fool ourselves, and some people can’t easily tell the difference — when things are bad enough, anything looks good.

Sometimes, there’s something I need to do — like, for example, to write one of these columns to meet a deadline. But I feel uninspired and one of the many other things that are usually on my plate look more appealing. I put it off. We have a word for that in Danish: overspringshandling. It’s actually an animal behavior that transcends our higher existence as humans, so it would be silly to deny that it’s part of us.

There can be a more sinister side to those who are driven. Preoccupation with work can be a substitute for an uncomfortable family life. It’s easy to stay late at work and to let the spouse deal with daily drudgeries of home life. Some people are trying to outrun the ghosts of childhoods lived in poverty and seek the gold ring as a token of security — an overspringshandling that creates workaholics. They are running from their former selves. And some aspire to a promotion, raise, or appointment that validates their own worth to themselves. These may be running from their true selves — or, at least, from their perception of their deepest self.

In knowing what motivates you, it’s sometimes interesting to ask what constitutes Done. How will you know when you are finished? When you cross the finish line in a race, the race is Done for you. Some people think of careers in terms of finish lines, and that qualifies a 10K race as a finite game that comes to an end and qualifies winners and losers (see Do the Right Thing). Others view a race as part of training regimen that is a stepping stone to running a marathon — still a finite game. But it’s not just about the goal. Pirsig, in Zen and the Art of Motorcycle Maintenance (William Morrow, 1974), tells us, “To strive only for some future goal is shallow.  ... [I]t is on the sides of the mountain where things grow. ... The top defines the sides.” Maybe you run to stay healthy so you can better enjoy life with family and friends.

A good career reflects a balance of focus and drive, with a perspective to not take work too seriously. There is more to career than work, and there is more to life than career. Enjoy the run, enjoy passing the mileposts along the way — but most of all, savour the experience, and stop to smell the roses.

Safety

The Retrospective Community recently suffered a crisis of safety on their discussion list because, well, the owner of the list said so. Safety is important but it’s almost always misunderstood. Let me discuss three spheres of safety in workplace interactions: physical well-being; emotional neutrality; and trustworthy engagement.

My sense of safety feels threatened in settings where too many of the knobs have been set to cultural values that are unfamiliar to me. My rental car was once broken into in Szczecin: they didn’t speak English and I didn’t speak Polish. They took my report at a police station through a government translator who hadn’t come there since the days that people entered the building permanently, never to emerge. Call that: “anxiety:” Fear of the unknown or unknowable (for both of us!) We find an extreme but real example from the contemporary high-tech world in the anonymous Tweets threatening rape against British journalist Criado-Perez for advocating women's’ likenesses on British currency.

The Retrospective Community finds safety in avoiding emotions. Many of them have been influenced heavily by Jerry Weinberg, who emphasizes that conflict resolution should take place on a rational plane. That’s where “I messages”, congruent communication, and active listening come from. Diminish emotional engagement, or shift verboten emotional responses to rationalism.

In a healthy community, I know that in spite of anything you say or do, that you are acting in the best interest of both of us. That gives you complete rhetorical freedom. We call that a community of trust. Such maturity lets people separate their safety from the uncomfortable feelings that arise in passionate debate.

Too many people equate organizational health with comfort, rather than safety. It ends being an ill-defined, almost drug-induced state of Candide bliss. But progress depends on upsetting the status quo. Shaw said, “All progress depends on the unreasonable man.” Guns, Germs and Steel ascribes much social advancement to war. Gever Tulley’s TED talk entitled “Five Dangerous Things you should Do with your Kids” makes more than a passing reference to cuts, burns and bruises.

Now, I’m not advocating conflict for its own sake, any more than I advocate progress for its own sake. But progress entails change, and change displaces people from their comfort zones. Improvement involves popping the happy bubble. When growing from walking to riding a bike, cuts and bruises are likely. That doesn’t imply we should seek cuts and bruises. But it also means that we should not count cuts and bruises as failure. To make an omelet, you’ve got to break a few eggs.

Agile leaders bear the responsibility to set the ground rules in their communities. Sometimes prior shared context is enough, but it’s more common that people come together with widely ranging interaction styles. Many leaders realize that responsibility in the form of covenants or team contracts. The problem is that most of them do it neither at the level of survival (it’s important to establish basic protocols of communication to quickly allow newcomers to engage) nor at the level of trust.

St. Augustine admonished us, “Ne quid nimis:” but everything in moderation. Good moderation comes naturally if people are comfortable at the Maslow survival level, and if the interactions are drawn upward towards a recognized common goal in a community of mutual trust. Artificially muted conflict is thinly disguised tyranny or censorship, and its goal is a false, artificially constructed sense of belonging in a trust-less environment. Let the good times roll, but let the storms rage as well. There is no sicker organization than the ones that silence tearful engagement.

Can You Scrum Art?

Cross-functional teams are a darling of contemporary agile rhetoric. It’s important to note that cross-functional can mean at least two different things. The  more pedestrian reading is that the team comprises all talent necessary to do its work. The more radical interpretation discounts specialization and holds that any team member can rise to any task germane to the goal. This latter perspective was popularized in Extreme Programming’s marginalizing of domain expertise. It lives on in Scrum courses where trainers admonish people that everyone should be a tester. If the only remaining work is testing, you will do testing. Part of being a team member is doing what needs to be done.

Malcolm Gladwell’s Outliers suggest that 10,000 hours of practice precede mastery. Agile folks often tell us that you can practice your way to cross-functionality. However, most people miss that Gladwell ascribes the roots of greatness more to social context than to will. Ericsson’s original 10,000-hour claim (The Making of an Expert, Ericsson et al., Harvard Business Review, July-August 2007) views intentional practice more as a precondition for success than as a means to success.

I think there is more than a grain of truth to the 10,000-hour argument, as discussed previously in Practice Makes Perfect. It’s healthy for Java programmers to grok UX tools, and vice versa. Teamwork is about shared knowledge and communication. Effective communication begs high context. Head knowledge provides some context but there’s no teacher like experience. Even Java programmers can intuit what a good interface looks like after building hundreds of them instead of just mechanically creating them using GOMs analysis and Fitt’s Law.

Behind the second form of “cross-functional” looms the spectre of a commoditized work force. You can assume plug-compatible employees for light unskilled labor. Programming is becoming a more common skill and, perhaps eventually, it will become natural to hire teams comprising members with adequate and relatively undifferentiated programming skill sets. Programming may become unskilled labor.

Become? Hmmm.

None of the 10,000-hour pundits ignore the importance of individual talent. Talent is of small importance in unskilled labor but it is everything in the arts. Even though the 10,000 hour number is commonly used to quantify the German nightclub practice that prepared the Beatles for stardom, no amount of practice is enough for some people to become opera stars. Not everyone can become a Rembrandt or, to shift disciplines, a Usain Bolt. Epstein’s The Sports Gene (Current Hardcover, 2013) dispels the 10,000-hour myth with genetics. This brings us onto dangerous ground: is it racist to say that Nigerians are naturally better runners? Is it sexist to say that women—another genetic consideration, right?—are naturally better computer scientists? (Read You Go, Girl! before answering too quickly.)

This begs the central question: is software product design purely a matter of science and manual labor, or is it an art? I’ve been corresponding with Peter Denning about the innovation process, and he’s convinced me that there are people who can design and some who just can’t. It’s the same with many other software product skills.

Talent matters in the application of many software disciplines. The first definition of “cross-functional” is still crucial: complex products draw on many disciplines, and most programs are complex products. Rather than trying to become an expert in all of your weak areas, practice them enough to be a good team contributor. However, focus on improving what you’re good at. And, of course, try many things: it may take a while to find your true calling.

Showing 1 - 10 of 57 results.
Items per Page 10
of 6
Advertisement
     
 

NEWSLETTER

Sign up for the Build Your Career newsletter to receive the latest career news and job listings.

 

 

 

View All Newsletters | Privacy Policy

 

 

Marketing Automation Platform Marketing Automation Tool