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

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.

Impossible Goals

When I teach project courses I often run an exercise that I call the Kaizen exercise. I challenge the class to a timed task that calls on their skills for self-organization and innovation. I challenge them again and again to complete the task in ever-shortening intervals. What starts as a two-minute task can be made arbitrarily short over a few iterations — five or six iterations in most classes, but shorter in some.

Sometimes, all that gets in the way of solving a problem is a lack of assuredness that the solution is even possible. We’re victims of the limitations of our experience and tutelage, and what those have portended for our experiences as professionals. So becoming informed about the boundaries of one’s practice and discipline are one way to raise your performance level. It’s not so much because it helps you learn how to do the things you learn about, but because it expands your horizons of what is possible. Steven Johnson, in “Where Good Ideas Come From,” (Penguin, 2010) calls this the adjacent possible. “The strange and beautiful truth about the adjacent possible is that its boundaries grow as you explore those boundaries,” Johnson writes. “Each new combination ushers new combinations into the adjacent possible. Think of it as a house that magically expands with each door you open.”

The new head of Toyota, Katsuaki Watanabe, set impossible goals for the company when the mantle of leadership fell to him. To create a car that could cross the United States on a single tank of gas. To create a car that by design could not harm someone in an accident. These impossible goals are worthy in their own right. But it goes without saying that it’s not about achieving those two feats, but about communicating a mindset of continuous improvement.

It’s a well-known human phenomenon that people change their appetite for an impossible task when faced with the reality, or even the possibility, that it has already been done. It is this, rather than development of human evolution or technique, that probably explains the frequent recurrence of sub-4-minute miles after Roger Bannister first broke the barrier in 1954 (four more did it within about a year, more than 20 leading up to 1960, and countless runners since them). Sir Hillary and Tenzing first climbed Everest in 1953; now, there are days when over 250 people try to make it to the summit.

Technology advances help too, of course, particularly in our field of engineering. Nature hasn’t yet caught up with Moore’s Law. Engineers should perhaps take pride that more of the advances in computer power  and scale have come at the hands of hardware folks than for software folks.

I used to believe that it was management’s job to challenge a team but now believe that while management should be the cheerleaders, coaches and water-bearers in such efforts, that challenge ultimately must come from within. Great motivation is intrinsic rather than extrinsic. Complacency is death, but ongoing self-directed exploration and sometimes irrational inquiry fuel progress.

It’s a great thought-provoker for reflection and a great conversation starter with colleagues: How many times in your career have you achieved what you once thought impossible? Make it a metric of your career to optimize the number of times you achieve the impossible. Doing what is possible is a matter only of science, since science is all about repeatability and following where others have gone before. The ultimate in innovation is doing the impossible, and doing the impossible perhaps takes an engineer.

Showing 2 results.
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