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

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.

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?