Agile Methodology Understanding Agile Methodology

A great way to improve your knowledge of Scrum is by attending one of the Scrum Alliance-sponsored Scrum Gatherings. It’s an opportunity to meet other Scrum users, attend sessions led by some of Scrum’s most important thought leaders, and learn more about the tooling and training solutions that are out there.

Most recently, the Munich Gathering was held in October, drawing hundreds of Scrum practitioners from across Europe and beyond to the three-day event. From all reports I’ve heard, the undisputed highlight was Jeff Sutherland’s extremely animated opening keynote.

Sound like an event you’d like to attend? The next Scrum Gathering will be held in Orlando, Florida, from March 8 – 10, 2010. You can learn more or register to attend by heading here.

Posted under Scrum

One of the best ways to illustrate how agile and Scrum can transform the way an organization manages its development is through case studies. Rather than simply saying that agile methods will streamline processes, reduce cycle time, and improve product quality, a case study illustrates how agile and Scrum can achieve those things. Moreover, they’re inspirational. When you can see that someone at another organization has experienced the same challenges and worked through them to successfully implement agile, it gives you the confidence to embark on that journey yourself.

Do you have an agile or Scrum transformation story you’d like to tell? If so, please post them here in the comments. To make things interesting, the person who submits the best one will receive a free iPod Nano.

Please make sure that the story you submit contains the following three sections:

• The Problem. What was going wrong at your organization that made you decide to implement agile or Scrum?
• The Application. Once your organization decided to use Scrum to surface dysfunction and transform its processes, how did you go about doing it? What were the first steps you took? Was it an organization-wide adoption or just on the team level? Did you use training or tools?
• The Solution. What was the result? Can you quantify the improvements that Scrum and agile helped realize? Have other teams at your organization begun adopting agile management techniques?

I look forward to reading your stories. Deadline for submission is Dec. 31, 2009 and please try to keep your case studies to between 500 and 750 words.

Posted under Agile Methodology, Scrum

Lately, “Lean”—which derives from the lean manufacturing practices popularized by Honda and Toyota in the 1980s—has been a popular topic in software development circles. Not only does much of agile development have its roots in Lean’s streamlined, waste-averse practices, but Forester just held its Business Technology Forum which focused on the new concept of “Lean IT.”

Over at ZDNet, columnist Joe McKendrick wonders aloud what this new term actually means and, more specifically, what it means for teams developing software. Citing Wikipedia’s definition of Lean IT as “vague and convoluted,” he ultimately expresses doubt that Lean IT is much more than a new name for waste-reducing activities that agile developers have been using for years. Without a doubt, McKendrick thinks there’s value in the principles being advertised as “Lean IT,” he just doubts that they’re all that different from strategies that organizations are already using. Read the entire post here.

Posted under Agile Methodology, Scrum

Scrum company Danube Technologies has launched a new series of video blogs, in which their team of Certified Scrum Trainers tackle various topics related to Scrum. So far, Danube’s posted two. In the first, Jimi Fosdick discusses what Scrum is and, in the second, Michael James continues the conversation by explaining why teams should use it. It’s great to see meaty video content for Scrum and agile users finally popping up on the web. Danube promises more video blogs soon, so be sure to check the company’s blog for the latest posts.

Posted under Agile Methodology, Scrum

DZone just posted a video interview with Danube Certified Scrum Trainer Michael James, in which he discusses the reasons organizations should trust Scrum to improve project management processes. He also considers what lessons Scrum practitioners can take away from high performing teams who work outside of software development. Catch it here: http://agile.dzone.com/videos/scrum-adoption-michael-james

Posted under Agile Methodology, Scrum

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.

Posted under Agile Methodology, Scrum

If you were unable to attend Agile 2009 in Chicago this past August, Agile Journal has your back. The site just uploaded a report in which Laszlo Szalvay, CEO of Danube Technologies, Inc., discusses the latest release of ScrumWorks Pro, which his company publishes, and its integration with Tasktop Pro. While ScrumWorks Pro 4 delivers powerful program management for enterprise customers, Tasktop Pro’s task-focused user interface offers developers a personalized view of all relevant work. Taken together, the two provide a complete range of functionality from a high-level organizational view to a drilled-down view of an individual’s work. Watch it here: http://www.agilejournal.com/media-center/videos?task=videodirectlink&id=81

Posted under Agile 20XX, Agile Methodology, Scrum

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