Agile Methodology Understanding Agile Methodology

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?

Posted under Agile Methodology, Scrum

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 here or watch a screencast here.

Posted under Agile Methodology, Scrum

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.

Posted under Agile Methodology, Scrum

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. You can take a look here.

Posted under Agile Methodology, Scrum

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 (you can read it here: http://www.danube.com/whitepaper/intro-to-agile) 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. Dzone, a website that frequently publishes “Refcardz,” i.e. reference cards on topics important for developers, just issued one on Scrum. It’s worth noting that it’s the first time one of DZone’s Refcardz to address a non-technical issue. 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.

A downloadable pdf of Michael JamesÂ’ Refcard on Scrum is below.

Scrum_Refcard.pdf

Posted under Scrum

ThereÂ’s no way around it: The Product Owner is part of the Scrum team. Granted, he or she doesnÂ’t do the heavy lifting of actual development, but the Product Owner is an indispensible part of the process. He or she communicates the vision for what is to be developed and defines the criteria by which it will be judged. 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.

If a Product Owner attends these meetings and attempts to redefine goals or scope, then itÂ’s probably a bad idea. In by-the-book Scrum, the Product Owner can attend these meetings, but cannot speak. And if the Product OwnerÂ’s attendance is disruptive, the team reserves the right to request that he or she not attend. Any time the teamÂ’s ability to self-organize is jeopardized, the Product Owner definitely should not be attending these meetings.

However, if the Product Owner truly understands the limitations of the role, he or she will respect the teamÂ’s ability to self-organize. In this instance, a Product Owner who attends daily Scrums can be an incredibly valuable asset. He or she can tell the team if itÂ’s on target or heading off-track on a daily basis, rather than only at the Sprint Review Meeting, resulting in a hyper-adaptive work cadence. But, again, this kind of high performing team depends upon the Product Owner and his or her ability to resist the urge to act like a traditional project manager.

Posted under Scrum

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.

Posted under Scrum