Hyper-Productive Knowledge Work Performance

The TameFlow Approach and Its Application to Scrum and Kanban

Steve Tendon, Wolfram Muller

• Publisher: J. Ross Publishing
• Year: 2014
• ISBN:
  9781604277579
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

By some estimates, knowledge workers outnumber all other workers in North America alone by a four to one margin. Knowledge work and knowledge workers vary with each profession, depending on the industry- from software developers to engineers, architects to pharmaceutical researchers, and so forth. They are usually responsible for exploring and creating ideas, new products, new designs or perhaps new models for doing business to help their organization achieve or maintain a competitive advantage. As much of this type of work is intangible, productivity is a mystery to most business executives, managers and team leaders.This unique reference shows how to lead knowledge workers, manage knowledge work and build a hyper-productive knowledge work organization, by taming and managing the four flows of organizational performance (psychology, information, work and finance) to produce spectacular operational and financial throughput results.Inspired by his experience and knowledge gained at Borland International, where a hyper-productive level of performance was achieved resulting in the most productive software project ever documented, author Steve Tendon devised TameFlow. TameFlow is an approach that can be superimposed on any preexisting process, method, and practice to enable performance improvement by several orders of magnitude and a state of hyper-productivity. It is adaptable to nearly every industry, and can be applied to any knowledge work domain or organization that generates business value through knowledge.TameFlow blends and merges different ideas from a variety of schools of thought. It is founded in pattern theory and organizational performance patterns which are used to analyze and decompose processes, methodologies, and management practices into constituent parts to observe productivity patterns, and then they are recombined in new configurations to enable hyper-productive levels of performance.In this volume, the TameFlow approach is explained within the context of knowledge work performed in a software development organization. Mr. Tendon teams up with author, Wolfram Muller, a thought-leader and expert in Critical Chain and Advanced Agile Project Management to illustrate its application to Scrum, the most widely used Agile software project management framework, and to Kanban, a method used for knowledge work with an emphasis on just-in-time delivery and change management.

Part I

---

TameFlow Principles of Hyper-Productive Knowledge Work Performance

---

1

---

A CASE OF SOFTWARE HYPER-PRODUCTIVITY

---

It has become almost an urban legend, but a well-grounded legend, that there is a software crisis. This belief originated in the late 1960s and more than 40 years later, the software industry still seems to be stuck in this crisis. Projects run late, cost too much, don’t deliver what is really needed, and so on. Software development seems like the realm of inefficiencies and underperformance.

It is also debatable whether the performance of individual programmers can vary by as much as an order of magnitude or not. Both anecdotal evidence and objective studies show this to be true. You don’t need to get acquainted with many programmers and see them at work to draw that conclusion yourself. It is a wise conclusion that über-programmers really do exist, and that they can outperform their peers by a factor of 10 or more.

From the early starts in mainframe rooms, the activity of programming has evolved from being the lonesome intellectual exercise of isolated individuals, to a concerted team effort requiring more and more collaboration between several individuals. There are many reasons for this. On the one hand is the emergence of software technology stacks—technologies that require specialized skills, from the back-ends to the front-ends, traversing all the middleware in between—and the always deeper knowledge needed for domain specific application programming. More people are required to master all of these skills—no one individual (with a few exceptions of legendary programmers), can truly know all of these technologies in depth.

On the other hand, the sheer size and scope of modern projects have grown to the extent that they can barely fit in the mind-space of a single, isolated programmer. To all this, we have to add the ever changing business environment and business competition that put even more pressure on being able to change more quickly. In short, any significant piece of software needs a team effort in order to be successful.

A legitimate question is whether or not a team can possibly reach levels of stellar performance similar to those of the individual über-programmers. Just bringing together a number of skilled individuals does not seem to cause this hyper-productivity to happen (though having good raw material to start with is obviously a prerequisite).

There have been countless efforts at taking average teams (a.k.a. immature teams) and improving them (making them more mature) through process improvement initiatives. The archetypal approach is represented by Capability Maturity Model Integration. However, even if teams undertaking such initiatives do indeed improve in a number of so-called process areas, they often are still only marginally better. It is rare that such initiatives make a real, substantial difference that can be counted in orders of magnitude of improved performance. Yet, there have been examples of teams that did this—software organizations that outperformed all of their competitors and software teams that reached hyper-productivity. One such instance is that of Borland International.¹

THE CASE OF BORLAND QUATTRO PRO FOR WINDOWS

When I (Steve Tendon) was at Borland, I didn’t know that it was a hyper-productive organization. I just noticed after leaving Borland that the other places I worked at were ... let’s just say, slower. It wasn’t until I read Jim Coplien’s papers (Coplien, 1994) that I realized there was a reason for this.

Actually, in that paper the term hyper-productivity was not even used—the most exciting wording referred to phenomenal productivity. In a later paper, Coplien (1996) coined the term hyper-programming, and only later did the term hyper-productivity appear in Jeff Sutherland’s many papers about Scrum.

Coplien’s work highlights how software development is a highly social activity, wherein the patterns of communication and interaction that happen between individuals are important factors. Traditionally, software development has been examined in terms of process rather than in terms of this social dimension. The study thus focused on roles that could be found in software development organizations. It is through the combination of roles and the communication and interaction patterns that happen in between them that a highly productive software development organization can emerge.

Most Productive Ever and Precursor to Scrum and XP

Software hyper-productivity is the capability of building production grade software at a speed that is greater by orders of magnitude than the industry standard. Coplien (2007) reported about the Borland Quattro Pro for Windows (QPW) project, at Borland International, describing it as most remarkable by any measure, and as setting the standard for Agile development in the early 1990s. Coplien also recounted how his earlier article from 1994 was influential on the formation of Scrum. In fact, Coplien’s study was highly influential on the shaping of both Scrum and XP and, notably, Jeff Sutherland, the creator of Scrum (Sutherland, 2012), writes:

We were prodded into setting up the first Scrum meeting after reading Coplien’s paper on Borland’s development of QPW. The Quattro team delivered one million lines of C++ code in 31 months with a 4-person staff that later grew to 8. This was about 1,000 lines of deliverable code per person, per week, the most productive software project ever documented. The team attained this level of productivity by intensive interaction in daily meetings with project management, product management, developers, documenters, and quality assurance staff. [...]

Each developer on this project generated 1000 lines of production C++ code every week for three years. In comparison, productivity on the recent Microsoft Vista project was 1000 lines of code per developer per year. The Borland Quattro Project was 52 times as productive as the Microsoft Vista project measured by lines of code.

To reiterate: A team of 8 people delivered 1 million C++ lines of production code in 31 months. As of today, this is still the most productive software project ever documented. But the performance feat was even more amazing! Coplien (2007) tells how the team actually made two prototypes before delivering the final product, and while the time was reported for those prototypes too, the corresponding code metrics were not included in the final count. So the actual productivity was much higher than the already amazing figures that were reported.

Barbarians, Not Burrocrats!

These events took place during the last years of Borland International’s legendary period (1982–1994), when the company was still led by the original founder (Philippe Kahn) and was fighting with Microsoft and Lotus for the top spots as a software superpower.

Borland International was extremely successful. For instance, it was the first company ever to make Microsoft withdraw from an entire market (the Pascal compiler market). Yet, in that fight, Borland International was the underdog, in terms of size and resources. The company had to do things differently.

Philippe Kahn had very clear ideas about what was needed (Weber, 1992): Microsoft was five times bigger than Borland, so Borland had no other choice but to become better, leaner, and faster than Microsoft. Better? Leaner? Faster? This sounds a lot like what is promised by current Agile methods such as Scrum and XP, and Lean methods (e.g., the Kanban Method). How did it work out at that time, when these methods were unknown? Philippe Kahn was inspired by the history of Central Asia, and how the nomadic tribes were able to expand into “civilized” Europe. In an interview, he described them like this (Weber, 1992):

They were austere and ambitious, eager for victory but not given to celebrating it. They were organized around small, collaborative groups that were far more flexible and fast-moving than the entrenched societies of the time. They were outsiders and proud of it. They were barbarians.

That idea of being organized around small, collaborative, flexible, fast-moving, outsider, and proud groups, was the key. The whole company saw themselves as Barbarians—Barbarians, Not Burrocrats! became the company’s unofficial slogan. It can be seen in Figure 1.1 as it appeared on a T-shirt that circulated in the company at that time.

Now, aren’t small, flexible, fast-moving, collaborative groups what Agile/Scrum/XP and Lean/Kanban are all about? Why then did not these methods lead to that software hyper-productivity that was seen at Borland?

Figure 1.1 The Borland Barbarians, as illustrated on a T-shirt of that period

Organizational Culture

The key to achieving software hyper-productivity is in the company’s organizational culture. Excellent technical skills are necessary, as are illuminated managers, technology, and infrastructure, along with software processes and methods—all of these are necessary, yet insufficient. The key lies in the organizational culture, and organizational culture starts at the top.

Philippe Kahn was known as an executive who had an understanding of software (Weber, 1992). In fact he was a computer scientist himself and certainly understood computers and software. However, he also understood the nature of software from a business and organizational perspective. It does not mean getting into the technicalities of programming and coding—it means understanding the nature of human creativity, and the individual and social processes that foster it, in an organizational setting. (We will explore this topic in greater detail in later chapters.)

Communication is another key ingredient. Even the most junior developer could e-mail Philippe Kahn and get a reply. Fisher (1992) wrote:

Borland insiders credit their “high bandwidth” communications with increasing the company’s efficiency. “If a programmer has an idea, he can raise it with everybody who matters in an hour, and have a decision made in two hours,” said Hamid Mirza, Borland’s vice president for database development.

What most people will reflect upon when reading the above quote is the flatness of the organization, but that is not the key point either. The key point lies in the frequency and patterns of communication. The flat organization is just a consequence of such communication and interaction patterns, not its cause.

Coplien came to the most important insight: his study of the QPW case and Borland International’s internal communication practices led him to appreciate and, above all, document the organizational patterns that can benefit software companies (Coplien, 1995, 1996, and 2004). It is within those patterns (and others) that you can find numerous, real elements that lead to hyper-productivity, as we will examine shortly.

LOSING HYPER-PRODUCTIVITY

The best evidence that software hyper-productivity stems indeed from the company leaders, and the culture they can instill in the organization, comes from Borland International itself. In 1995, after considerable growth, professional management (yes, the Barbarians are still laughing today) took over, and replaced Philippe Kahn. After a series of management blunders and numerous changes in strategic direction, the company declined and eventually settled on making software test and quality tools with a focus on application life-cycle management solutions.

Most stunning, in the meantime the company had lost all of its original hyper-productivity. This became ironically evident in 2008 when Peter Morowski, then Borland International’s Senior Vice President of Products, wrote an article for the Agile Journal (Morowski, 2008) telling how between 2006 and 2008 he had lead an Agile enterprise transformation program. Go figure!? The company that held the unmatched software productivity record, had inspired Scrum and XP, and had given Coplien the raw material t...

Table of contents

• Cover
• Title
• Copyright
• Table of Contents
• Foreword
• About the Author
• Acknowledgments
• WAV™
• Part I TameFlow Principles of Hyper-Productive Knowledge Work Performance
• Part II Hyper-Productive Scrum and Kanban: Applying the TameFlow Perspective
• Appendix A
• Bibliography