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.

When youÂ’re working on a development team thatÂ’s managed traditionally, knowing how best to convince management to begin using agile methods can be incredibly difficult. When I found myself in that position, I repeatedly approached my project manager to make a case for Scrum. I told him it would help our team produce functional software sooner, at a lower cost, and with less anxiety for the both of us. But he didnÂ’t really hear what I was saying until he heard it from someone else. More specifically, I passed on a great white paper on agile development and Scrum that did my talking for me. Once my manager heard someone elseÂ—who had been doing agile and Scrum in a professional capacity for yearsÂ—say exactly what IÂ’d been saying, it persuaded him to take agile seriously.

Well, I just found another document like that one and I’m excited to share it with you. It’s also worth noting that it was authored by Michael James, a Certified Scrum Trainer with some truly impressive credentials and deep experience transforming organizations to Scrum. Making it all the more ideal for pitching Scrum to management, the Refcard is organized in a way that information can be absorbed even at a glance (lots of bullets, lots of illustrations). It begins by considering the basic makeup of the Scrum framework, such as its roles, meetings, and artifacts. From there, James considers what kinds of projects need Scrum the most, what relationship it bears to other practices (like lean manufacturing), and how large organizations can cope with the challenges of scaling. It doesn’t cover everything (not even close), but it covers enough to get the attention of your project manager—especially if he’s seen some failure lately.

In one sense the Product Owner is part of the Scrum team. The Product Owner communicates the vision for what is to be developed and revises priorities. However, that doesn’t mean that the Product Owner should be involved in every aspect of development. One particularly hard question is whether the Product Owner should attend the team’s daily Scrums (or daily standups). And the frustrating answer to that question is: It depends. Our usual suggestion is to try it whichever way you haven’t been doing it in the past, then use the Sprint Retrospective Meeting to reflect on how it went.

Most of the time people ask us this question, we find the person playing the Product Owner role is actual a proxy instead of the real business decision maker. For example, if you don’t have the authority to cancel development, you’re probably a proxy, not the actual Product Owner. Often we discover the Product Owner proxy’s boss is the real Product Owner. So a problem with stating the Product Owner must always attend the Daily Scrum is that it encourages organizations to choose Product Owners who have too much free time instead of the real decision makers who might not be available (or even necessary) daily. Ken Schwaber, who wrote the original books on Scrum, recently wrote about the downsides of a low-level Product Owner as encouraged by some XP folks.

For new teams, the most frequently overlooked problem with involving the Product Owner in the daily Scrum (and also the Sprint Retrospective) has been described as the invisible gun effect. Even when the Product Owner doesn’t try to dominate the meeting, the presence of someone with power and responsibility in the organization will prevent the team from stepping up to the same degree of self management. For more information about the invisible gun effect, see the Sprint Retrospective Meeting elearning module, Is My Boss On the Scrum Team? or an upcoming book by Adam Weisbart.

Other teams have found it beneficial to include the Product Owner in the daily meeting, especially once their self organization habits are better established. As suggested, try it whichever way you haven’t been doing it in the past, then use the Sprint Retrospective Meeting to reflect on how it went.

When I first heard about Scrum, I decided to educate myself by reading up on it. But the more I read, the more Scrum seemed to be a deeply intuitive framework based on common sense. I wondered, Â“Why isnÂ’t everyone working this way?Â” But I didnÂ’t realize just how big of an impact Scrum could make until I attended a ScrumMaster Certification course and had the chance to simulate the Scrum process firsthand.

Suddenly, what appeared straightforward, even obvious when I read about it became complicated. Working with team members who had different levels of experience with Scrum and conflicting ideas about what direction to take the project (in the simulation, a brochure for Martians visiting Earth) meant that we had to really trust the roles and processes of Scrum to lead the team to success. Which is exactly what we did: The Product Owner communicated her vision and the acceptance criteria sheÂ’d be judging our work by. The team then worked to create a brochure that met those criteria, checking with the Product Owner throughout the simulation to ensure that we were staying on track. In all, we replicated an entire sprint over the course of a few hours.

Interestingly, that experience of seeing how ScrumÂ’s processes and principles play out in a team setting was just as valuable as all the reading I had done. Just through a short, hands-on exercise, I saw how self-organization works, how hard it is for a Product Owner to resist micromanaging, and how two-week sprints force teams to get to work, rather than waste time gathering requirements. It prepared me for real world Scrum by showing me the strengths of the framework and the challenges of teamwork.

To those who have been reading a lot about Scrum, but have never practiced it, I would urge you to consider Scrum training. Not only does it provide a foundation of knowledge about Scrum, but itÂ’ll give you your first taste of actually working within a Scrum paradigm. And that experience Â— even in simulation Â— brings ScrumÂ’s exciting potential to life.