Vikas Hazrati filed a fascinating report recently over at InfoQ, in which he discusses an experiment conducted by agilist Steve Bockman. In the experiment, Bockman tasked eight subjects to build a particular kind of paper airplane within a five-minute time box. He then provided three different ways to learn how to construct the airplane: written instructions (i.e. documentation); a completed airplane (i.e. reverse engineering); and step-by-step demonstration (i.e. mentoring). The results showed that a mere 12.5 percent of the test subjects could successfully replicate the airplane design using only documentation, while 25 percent could build it once they had a completed plane to study. However, 100 percent of the test subjects were able to successfully build the airplane when Bockman walked them through every step of the process.

This is especially interesting to me because of its relevance to agile methodologies. For example, in software development, there is a name for step-by-step demonstration: Pair programming. Agile organizations will often pair an experienced developer with a relative newbie so that the less experienced developer can Â“driveÂ” while the veteran developer observes and provides guiding feedback when necessary. Many traditional project managers regard pair programming as a waste of resources (the common criticism is that itÂ’s using two people to do the work of one), but BockmanÂ’s experiment suggests that such an investment in teaching through demonstration or mentoring is infinitely more effective than other means.

What are the most effective teaching methods your organization uses? Have you had experiences that contradict BockmanÂ’s study? Please leave your thoughts in the comments section.

In a recent post at InfoQ, Mike Bria reports on two recent articles by Johanna Rothman which discuss best practices for agile implementation. The right way to go about an agile transformation is a controversial subject, in which some agile practitioners advocate an Â“all-inÂ” approach to adoption and other recommend a Â“toe-dippingÂ” strategy. According to Rothman, both approaches are valid, but what matters is the context in which these approaches are applied. Rothman recommends that an Â“all-inÂ” approach is appropriate, but only at the project level. Similarly, she believes that Â“toe-dippingÂ” is also a good idea, but, again, only at the organizational level.

This is consistent with other literature IÂ’ve read on the subject. And, at least for those who know agile and Scrum well, an understandable piece of advice. After all, by beginning an agile transformation with a by-the-book implementation at the project level, the organization can expand its installation in an incremental and iterative fashion. (Sound familiar?) That is, this method actually harnesses agileÂ’s most important principles to provide a framework for expanding it throughout an organization. For example, just as agile does not require development teams to identify all requirements of a project at the outset, an isolated deployment of agile functions like a pilot, allowing the team to observe impediments and collect requirements (and best practices) as the team makes its way through its initial sprints. Once this pilot team feels it has a strong understanding of project management with agile and has amassed some best practices, itÂ’s time for the organization to take the next step in an incremental rollout and create a second agile project team.

Because agile represents such a significant shift in both how work is done and how teams conceive of work, implementing agile at the entire organization from the outset would likely result in disaster. Considering that the single biggest impediment to successful Scrum adoptions is cultural, beginning with a pilot team allows a supportive buzz to build throughout the organization that will lessen resistance when other teams are asked to adopt agile methods.

I just came across a really interesting read on the Dr. DobbÂ’s site. In Ivar Jacobson and Bertrand MeyerÂ’s article Â“Methods Need Theory,Â” the two consider the natural impulse for the creator of something to tout it as the latest and greatest. Drawing parallels to the fashion industryÂ’s flash-in-the-pan fads, Jacobson and Meyer suggest that software, like fashion, is not immune to the crazes its most influential tastemakers promote. Certainly, software has seen various management paradigms rise and fall in terms of popularity and the majority of their article focuses on todayÂ’s most headline-grabbing trend: agility.

Now, agile has been repeatedly taken to task for being a vague method. After all, itÂ’s really just an umbrella term that collects all the practices that fall beneath it. Of those, several which had their heydayÂ—DSDM, CrystalÂ—have fallen by the wayside. Scrum seems to have emerged the victor in this fight, with its careful balance of structure and flexibility.

One interesting thing to note about Scrum is that it was, in large part, inspired by complex adaptive systems theory, which is, in essence, a theory of evolution. The idea was that Scrum teamsÂ—through regular points of inspection and adaptationÂ—would follow the path toward survival, much like a species learning to adapt in the midst of an evolving climate or food chain. This article, written by Laszlo Szalvay of Danube, a Scrum company, suggests that, if thatÂ’s the case, Scrum has a mechanism built into it to ensure that it stays relevant to emerging conditions.

What do you think? Are Scrum and generalized agile flavors of the week or built to last?

Most agile methodologies were created to be used with small teams who are all located in the room. So what happens in agile environments where there are many teams, some of which are un-collocated, working on complex development projects? The answer is to employ an agile tool. However, agile tools have historically focused on communication and collaborationÂ—that is, they have been most effective at simply uniting team members who are geographically distributed, ensuring that everyone is apprised of task progress and other critical updates. But as agile methods continue to grow in popularity and are increasingly adopted by large organizations, agile management tools must keep pace with the amplified complexity of developing software within such environments.

One of the most common challenges faced by such organizations is program management. That is, because many organizations develop product features that will be utilized across a range of products, it is necessary to monitor progress at the program level (where the completion dates of various product features converge to create the product itself).

Luckily, software publisher Danube Technologies has been paying close attention to the problems faced by agile practitioners working within deeply complex development environments. Its ScrumWorks Pro tool has always delivered great collaboration and task management functionality, but now ScrumWorks Pro 4 addresses the need for a robust program management platform with the concept of Â“Epics.Â” Epics allow users to create cross-product themes at the program level, which, in turn, percolate down to the constituent products. In essence, an Epic is like an uber-PBI, which has its own scope and allows organizations to gauge progress not only at the Epic level, but also across multiple products, a single product, or programs.

This is a major step forward in program management. You can read more about this release of ScrumWorks Pro.

As Tech Republic’s Rick Freedman tells it, every time he posts on an agile topic, the most common argument he hears against agile methods is against the concept of estimation. That is, without exhaustive requirements documentation, how does a development team know what to do or even where to begin? Freedman’s right: This is, by far, one of the most prevalent knocks on agile. But in a post titled Â“Estimating the Unknown,Â” he makes a good case for why agile’s lack of comprehensive requirements gathering is nothing to get too worked up about.

According to Freedman, the first things that any development team will ask upon receiving a project are: 1) How much budget do you have? and 2) When does it need to ship? But, interestingly, in a more traditionally managed environment, the team would still put together an enormous list of requirements as if the project’s conditions were not limited in any way. Of course, they are limitedÂ—by budget and timeline. As Freedman suggests agile simply rephrases the question from Â“How much for all these features?Â” to Â“How many of these features can you include within this budget and time-box?Â” In essence, agile acknowledges that work does not occur in a vacuum, but is, in fact, subject to real-world conditions.

What Freedman doesn’t entirely address (he hints at it in the last sentence or two of the piece) is how requirements, like development in an agile environment, are gathered incrementally. That is, agile teams can afford to push some of the requirements gathering to later in the development cycle, when more information about the product is known. During that initial sprint, the team really only needs to know which functionality is most essential to the productÂ—the rest will become clear through sprint review meetings with the Product Owner and customer.

Because agile project management places a special emphasis on the team dynamic (as opposed to the contributions of individuals), IÂ’m always interested to pick up great ideas from hyper-performing teams that work in other fields. This interest started when I had the good fortune to see a presentation by Certified Scrum Trainer Michael James that attempted to uncover the patterns of those teams that seem to achieve the impossible. His examples came from across the boardÂ—psychology, avionics, improvisational theater, and jazz. And the patterns he identified truly enlightened what it takes for a team to push itself to evolve into a hyper-productive entity. For example, James found that certain personality types donÂ’t contribute much to team dynamics in which responsibility is sharedÂ—and that pairing particular personality types on the same team can be nothing short of toxic. He also found that certain elements needed to be present to keep team members from becoming too comfortable. For example, jazz musicians and improvisatory actors require an audience to elevate their performance. Without an element of risk, such performers do not encounter the threat of failure, which also serves as a compelling motivator. In all, there was far too much in his presentation to succinctly recount here. However, as a frequent reader of his blog, I just saw a similar post, which recommends a short book written by Marine General A.M. Gray which suggests that, for teams engaged in military combat, skill and speed are just as important as size and strength. As James astutely observes, Â“Effective Scrum teams, with business-savvy Product Owners, have also learned to outmaneuver larger competitors.Â”

James highlights a handful of especially relevant quotes and provides a link to General GrayÂ’s text online.

There are a lot of blanket statements made about agile from both sides. Proponents say Â“agile is a silver bullet.Â” Detractors decry agile as complete chaos. Of course, neither of those ends of the spectrum are very accurate. But it can take folks a long time to arrive at that realization. Recovering project manager Andrew Makar writes about this experience on a recent article on the Gantthead website, titled Â“Agile Myths Debunked.Â” In it, he recounts how, several years ago, he and a colleague shared a laugh over a vendor championing Â“extreme programming.Â” Now that agile and its engineering practices have grown up quite a bit more, Makar remarks, Â“IÂ’m not laughing anymore.Â”

In the article, he goes on to list four major misconceptions he had about agileÂ—ThereÂ’s no documentation in agile! ThereÂ’s no planning in agile!, etc.Â—and, one by one, explain how heÂ’s seen those myths debunked through real world experience. IÂ’m not sure any experienced agile practitioner will find much here that will surprise them, but thatÂ’s hardly why itÂ’s a good read. Instead, itÂ’s satisfying to step back and consider how far agile methodologies have advanced. Truly, it wasnÂ’t very long ago that these types of criticisms were leveled at agile and, in an article like MakarÂ’s, theyÂ’re held up as evidence of how far our thinking on the topic has come.

What do you think? Have you seen the acceptance of agile methods and techniques grow in acceptance in recent years? Or do you perceive that folks are still clinging to the Â“mythsÂ” Makar outlines?

Craig Larman and Bas Vodde have published a list of the top ten impediments organizations face when attempting to adopt agile management methods, based on a survey of agile experts at very large companies. Now, I know most of us don’t like to be reminded about what we’re doing wrong, but, frankly, that’s exactly why I’d recommend taking a look at this. You might recognize some of these anti-patterns. In fact, some may be much too close to the bone. Of course, being aware of the anti-patterns we perpetuate in an agile environment is the first step toward eliminating them.

I won’t spoil the countdown for you, but I will speak to a pair of impediments that the authors mention that were not reported by the survey respondents:

“A culture of individual workers rather than real teams and teamwork;” and

“The gap between people in management roles and those doing the hands-on work.”

Both of these impediments boil down to an issue of “culture,” which I would argue is the single biggest obstacle preventing teams from successfully implementing agile practices. Why? Quite simply, if a team is unprepared for or unwilling to acknowledge the fact that agile is significantly different from traditional management paradigms, then it will continue to operate according to the status quo. For change to truly stick at an organization, all of its employees—from management to “those doing the hands-on work”—must understand the magnitude of the adoption and revise their working methods accordingly. When a culture embraces the changes precipitated by an agile adoption, those values can quickly move throughout an organization and allow process improvements to take place. But if the culture obstinately clings to old, familiar ways of working, there’s little chance of it evolving.

Lately, there’s been a lot of talk about how agile—and Scrum, especiallyÂ—can help organizations weather this economic downturn. After all, by employing a project management framework that helps teams to continuously improve their own processes, an organization can essentially do more with less. But in this article from the March 9th edition of the Wall Street Journal, we get a little empirical evidence that agile values pay off.

According to reporters Timothy Aeppel and Justin Lahart, many U.S. manufacturers haven’t been hit as hard by the recession as companies in other industries. The reason? Over the past few decades, Lean Manufacturing ideas and techniquesÂ—the same concepts that led to the agile movement in softwareÂ—have helped them streamline operations to the extent that many complex operations are handled by only a few highly skilled individuals. As a result, employers have been able to avoid making dramatic cuts, while employees have been able to enjoy a heightened sense of job security. From an even bigger picture standpoint, Lean Manufacturing helped ensure that the American manufacturing sector was one of the last industry’s to begin feeling the pain of the recession.

Most relevant to our discussions of agile techniques and project management in general was a description of a team at Parker Hannifin Corp. in Spartanburg, South Carolina:

“At Parker’s Spartanburg plant, five workers make the tiny plastic rings that become seals on aerosol cans. Each member of the group runs a different set of high-speed machines doing a distinct step, such as extruding long noodles of plastic, grinding them or cutting them into final product.”

For Scrum practitioners, this approach to team composition is very familiar; we call them Â“cross-functionalÂ” teams. And just like with development teams, the value of grouping individuals with varying skill sets (that do not necessarily overlap) is that the team can share their unique perspectives to collaborate strategically, while carrying the entire project to completion without handing it off to someone outside of the team. As the article goes on to explain, this arrangement also offers employers cost-cutting options other than layoffs.

“The group can curb production several ways short of layoffs. Two workers can complete the first two steps in one day, then the other three workers can finish those products the next day, essentially cutting everyone’s hours by half. Or, all five can take whole days off together. But permanently pulling one or two of them out of the mix is far more difficult to accomplish, and could make it impossible for the line to operate efficiently.”

Perhaps unwittingly, the reporters have described a kind of process of self-organization, in which how the work gets done is secondary to the fact that it is satisfactorily completed by the deadline (and without going into the red). But, above all, I found this article to be a fascinating real world example of how cross-functional teams do, in fact, help organizations do more with less.

Over at SD Times, Andrew Binstock has a bone to pick with agile evangelism. In some ways, I sympathize. I’ve certainly read enough testimonials from born-again agilistas to know that their views aren’t always realistic. As Binstock points out, agile is not the “one true path.” In fact, there are several methods by which one could successfully manage a complex project—and one of them is waterfall. If your company is meeting its deadlines and staying within budget while using a waterfall approach to development, don’t change a thing. After all, there’s no point in messing with a winning formula.

Agile can be an indispensible asset to an organization, however, when that formula isn’t winning. If a team is missing deadlines and burning through budget, delivering a product that disappoints the customer, or generally doing a poor job of behaving like a team (i.e. communicating, pairing on work, etc.), then it might be time to turn to agile. And even then—it’s not a quick fix. Agile tends to push team members to think and behave differently, which can be a real shock to the system. Factor in the critical importance of following—really following—the principles and processes of agile and it can seem like a very disruptive change, indeed. However, it’s the sort of pain that hurts a lot at first, but goes away altogether over time. (You could call it “healing.”) Once a team has adopted and internalized the agile paradigm, its familiarity will provide the team with a grounding set of practices and a roadmap for iterating their way out of challenging scenarios.

By the way, Binstock’s assessment of Winston Royce’s presentation of waterfall as a “stuffed man” is exactly right. At the time of his presentation, he warned that his design would need to go through at least a second iteration before it would have much chance of succeeding. So, really, Royce presented a kind of phased version of waterfall, which lacked agile’s cross-functional teams, but anticipated its use of multiple iterations.