Agile Methodology Understanding Agile Methodology

From where I write, 2009 was a banner year for Scrum and agile. Not only did these project management methods continue to grow in popularity and usage, they importantly spread into the largest, most complex development environments (enterprise-sized companies). But looking at SDTimes’ recap of the past year, they dubbed last year “the year of the cloud.” Certainly, the rise of cloud computing has made a huge impact on the way we store and share information—there’s just no denying it. But it’s good to see that Scrum and agile are on the magazine’s radar for the coming year. The SDTimes staff is already expecting big things from agile in 2010. Here’s how they put it:

“Agile computing is maturing. It’s not just a manifesto anymore: Many development shops have adopted agile practices. Some have gone deep and are religious about Scrum, Extreme Programming or some other methodology. Others are guided more by the agile philosophy and have chosen elements of various methodologies to create their own lean practices. Only the most highly entrenched organizations are untouched by agile.

“The questions now: Where does agile go from here? Does it just fade into a set of best practices? Indeed, is there even an agile movement any longer? We’ll see changes and evolution here in 2010.”

Any predictions? Where do you think agile will go from here? What will see in the coming year? Please peer into your crystal ball and make your prediction in the comments section.

Posted under Agile Methodology

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

I just saw this post on InfoQ and it struck me as a really valuable offering for the software development community. For agilists, the idea that learning by example is the best way to learn is embedded in such techniques as pair programming, in which an experienced developer “navigates” and a relative newbie “drives.” Well, now Antony Marcano and Andy Palmer’s project PairWithUs translates that idea into a series of documentary-style segments that capture the two as they program together. In their words, the project is “agile software development (user stories, tests, code and more), broadcast live and recorded for your future viewing pleasure.” As such, each segment provides a screenshot of code coupled with their commentary—as Marcano and Palmer talk through the problems they encounter and brainstorm ways to overcome them. This is a great way to help spread best practices and offer insight into dealing with various obstacles. You can watch more than 70 segments they’ve taped thus far here: http://vimeo.com/user1477180/videos/page:1/sort:newest

Posted under Agile Methodology

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

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.

Posted under Agile Methodology

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