Agile Methodology Understanding Agile Methodology

Just because you’re doing scrum, doesn’t mean you’re off the hook with finance and management when it comes to giving a real estimate for completion. Scrum, as most agile processes, takes the approach that cost and time are fixed and that it’s the scope (or features) that are variable. “You’ll rarely be remembered for missing a feature…but you’ll never be forgotten for missing a schedule”….. Which is why it’s important to make sure that communication with all stakeholders is crisp and that they understand how projects are being scheduled. Ken Whitaker has written a detailed article on The Agile Schedule posted on gantthead.com. The article is fairly technical and includes concepts such as the “cone of uncertainty”, “rough order of magnitude”, and “definitive scheduling”. When I took the ScrumMaster certification course we covered these concepts at a high level. We also talked about backlog grooming and why a good and consistent backlog grooming will do wonders for improving release scheduling. Although backlog grooming is not a formal component of the Scrum process, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. Everyone should attend the backlog grooming meeting and help the Scrum product owner prepare the scrum backlog for the next sprint planning meeting. Activities during this meeting often include breaking epics into stories, adding stories to the backlog, clearly defining acceptance criteria and more. If this is done on a consistent basis you will greatly improve your agile release planning.

Posted under Agile Methodology, Scrum

By now, it’s practically accepted that software development and project management, generally, are being re-imagined by agile management techniques. But in a recent article on Projects@Work, called “Agile Drivers,” CST Angela Druckman explains why that is. As she explains, there are six factors that are driving agility in organizations—and they’re changing the way we conceive of doing business. To summarize, the six factors she identifies are:

• The “hero” mentality gives way to collective intelligence.
• Small teams rule.
• Stop applying pressure, start removing impediments.
• Focus on business value.
• Distributed teams are the norm, not the exceptioin.
• Roles will change.

Sound like some topics that have been on your mind lately? If so, I encourage you to take a look at DruckmanÂ’s article here.

Posted under Agile Methodology, Scrum

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