Learn all about scrum & agile programming

Uncategorized

Building the Product Backlog

Building and maintaining a Product Backlog can be a time-consuming effort. Though the Product Owner has final say in the prioritization, a good product backlog is a result of a combined effort of the entire team – Product Owner, Scrum team, ScrumMaster and stakeholders.

One expert in this area is CollabNet Certified Scrum Trainer Angela Druckman. Ms. Druckman will be hosting a webinar focusing on techniques and ideas for improving the overall effectiveness of backlog management.

The webinar will be held on Monday October 27, 2011 at 11:00 am pacific time. You can register at the CollabNet website www.collab.net – www.collab.net

Agile’s Glass Deck

Visibility is one of Agile’s key benefits. What if there was transparency all the way from the top of the management chain down to the bottom ranks of the development “crew”. Or in otherwords, kind of a glass-see through deck? It seems that everyone on that ship would benefit from the agility or added maneuverability realized through information being fed top down as well as bottoms up.

Christine Crandell explores this topic in a recent article entitled, Why Your Boss Should Also Go Agile”, on the Scrum Alliance website. One commentator summed it up well, “There is growing understanding that transitioning to Scrum is a cultural change, not just a team process change. A culture change requires that “leaders” (wherever they are in the organization – including senior management people) understand the changes, understand what it means for them, and understand the objectives….it is critical to have your boss and his boss (and his boss…) support such a transition.”

Does your boss support you and your team’s adoption of agile? If not, what are there objections? If so, what helps them understand and support agile adoption?

Hyper-Productivity with Agile

Today it is generally recognized that agile teams outperform traditional “waterfall” teams with respect to time to market and productivity. Some estimates say that agile teams are 25 to 50 percent more productive than their traditional peers. Others say this number can range from 400-800 percent more productive.

So what are these hyper-productive teams doing differently to achieve such extraordinary results? Ryan Shriver has written an interesting article exploring this topic. http://www.gantthead.com/content/articles/255949.cfm Ryan’s article is based on Dr. Jeff Sutherland’s experience with hyper-productive agile teams.

In this article Ryan outlines the 12 best practices that Sutherland and others attribute to hyper productive team performances. In addition he describes the engineering practices that hyper-productive teams adopt.

In this article one of the best practices that Ryan covers is the concept of “pairing”, when two developers work side-by-side on one computer to implement a story. Working as a team they can work much more quickly than if they worked independently. In addition, pairing helps to mitigate risk and overdependence on key resources that can have a negative impact on productivity.
http://www.gantthead.com/content/articles/255949.cfm According to Ryan, while the practices he describes are simple in concept, those teams that stick with them have historically performed at levels that are hyper productive and far exceed their peers.

Are Traditional Management Practices and Scrum Incompatible? Not So, Says Cohn

Right now, one of the hottest topics in the Scrum community is whether or not traditional, PMI-style project management can coexist with Scrum or agile methods. Mike Cohn, an agile guru and an early champion of Scrum, believes they can be compatible, but introducing new ways of working needs to be handled sensitively to manage the disruption, confusion, and possibly fear that accompanies any large-scale work-place change.

Scrum and agile practitioners have long held that the largest impediment to a successful agile or Scrum adoption is simply the culture of the organization. It is human nature for change to be scary, so how that change is presented to the organization can make an enormous difference in how employees respond. Quite simply, organizations should heed the tenets of Scrum and agility, which include transparency and frequent communication. When every member of an organization is kept in the loop about a change, there’s little room to feel “in the dark.”

According to Cohn, there are four major steps an organization can take to smoothly introduce agile practices—and pulling it off requires ample sensitivity. To summarize, he suggests that Scrum and agile change agents do the following: 1) “negotiate and set expectations up front,” 2) “fit your reporting to current expectations,” 3) “invite them [key stakeholders] into your process,” and 4) “reference a success.” It’s strong advice that’s worth a look. You can read the entire post here: http://www.ebizq.net/blogs/tai/2009/12/the-art-of-compromise-scrum-and-project-governance.php

The First Tool for the Enterprise

Finally, it seems agile tools are catching up to the real world demands placed on organizations managing large, complex projects with agile methods—especially those companies who are developing products with shared components. While agile tools have done a great job of connecting teams to help keep even un-collocated team members frequently communicating, the biggest drawback of agile tooling options has been their capacity to translate in complex development environments. For example, it’s extremely common for large organizations to develop applications which are then utilized in multiple products. However, no tool has satisfactorily addressed that issue, making it near-impossible for such organizations to gauge the overall progress of a project, since it includes multiple backlogs.

But ScrumWorks Pro 4, which has just been released by Danube Technologies, has taken some big steps toward giving enterprises the ability to accurately track progress in situations like these. In the latest release of ScrumWorks, its two-paned interface highlighting the sprint and product backlog has been expanded to include a third view: the release planner. The release planner will allow users to define product features at a high level and assign themes (i.e. searchable/sortable tags) to the various products that will utilize this feature. Because programs (or “epics”) are created using themes, ScrumWorks 4 offers highly flexible program management capabilities and, importantly, allows users to configure the tool to reflect their own development activity, rather than work around the limitations of a tool.

If you’d like to learn more about ScrumWorks 4 and its features, head here.

An Inside Report on the Toyota Production System

I’ve written on how the Lean Manufacturing movement has helped shape agile development practices before on this blog, but I just came across a blog that gives readers an inside view into how Lean Manufacturing and the Toyota Production System, in particular, actually look in a contemporary Toyota factory. Certified Scrum Trainer Michael James, who recently authored a great introduction to Scrum, posted this blog about his recent visit to Toyota’s manufacturing plant in Japan. James weaves together review of the principles that constitute the Toyota Production System along with his first-hand impressions of touring the plant. Balancing a discussion of important aspects of Lean with personal essay, it’s a fascinating glimpse into these principles in action. Highly recommended.

How is Lean Different from Agile?

As we all know, one of the precursors to agile development was the Lean Manufacturing movement, typified by the work of Japanese automakers such as Toyota and Honda in the 1980s. So, clearly, they’re related. But InfoWorld’s Martin Heller has just posted a blog that explains how, when it boils down to philosophy, agile and Lean go their separate ways. Yes, both agile and Lean “strive to improve software quality, reduce waste, increase developer productivity, accept changes to requirements, and prize meeting the customer’s real needs.”

So what’s the difference between the two? According to Heller, the difference exists in relation to the business. As he sees it, agile is too preoccupied with software development processes, whereas Lean attempts to address every level of production, including the supply chain.

Now, this got me thinking. As I understand it, agile—and Scrum, especially—are uniquely synchronized with the business. Prioritization decisions are driven by what Business Value a given Product Backlog Item will generate. And iterative, incremental development provides a natural point of contact with the customer at the end of every sprint. Moreover, is agile development really that specific to software development? Aren’t its principles actually derived from new product development? And couldn’t they just as easily be utilized to manage complex projects in any industry? I’ve probably made my position clear through all those questions, but I’m more interested to hear what you think about this. Does Heller’s assessment of Lean and agile square with your own understanding of them?

Lean Reading

In my posts on this blog, one common forerunner to agile development practices that I have repeatedly mentioned is lean manufacturing. Also known as “flexible mass production,” lean practices were popularized by Japanese automakers such as Toyota and Honda in the early 1980s. Key to this practice is the belief that any resource used that does not contribute toward production is wasteful and therefore must be eliminated to improve processes. Thus, the entire process can be summarized as attempting to do more with less. But chances are you know that much already. If you’re looking to dive deeper into Lean, InfoQ has posted a list of 24 books on the topic recommended by agile users (and even more are trickling into the comments section). You can take a look here: http://www.infoq.com/news/2009/05/lean-books