Though traditional project management and Scrum have long been viewed as antithetical ways of working, that’s not quite right. It would be more accurate to say that Scrum simply responds to and refines the shortcomings of traditional management practices. Still, as Scrum and other agile methods have continued to grow in the past few years, many PMPs have begun reassessing Scrum and agile to see what aspects of those methods it can utilize. On the PMI website, they’ve just run a short interview with an individual who straddles both worlds: Jimi Fosdick, who is both a PMP and a CST (certified Scrum trainer). According to him, it’s still possible for traditional project management and Scrum and agile to coexist. Still, he’s quick to point out that there are major challenges. Of those, he cites the following as the most irksome:

“Organizational Structure: Companies aren’t usually set up to handle the way the work is done in scrum and agile–and that’s a very difficult thing to change.

“Corporate Culture: Scrum is built on the principles of self-organization and self-management. So the development team doesn’t really have a boss or a manager telling them what to do. And that’s very scary for a lot of organizations. There’s a prevailing belief–left over from the scientific management of the 1950s and 1960s–that unless you’re watching what your people are doing, they won’t complete the task at hand.

“False Assumptions: Many of the policies and progress metrics in place in organizations and the artifacts and reporting required, are often counterproductive and run contrary to scrum. Some tasks–like needing sign-off on a full requirements document before development can start–interferes with the ability to do something in an agile way.”

You can read more here: http://blogs.pmi.org/blog/voices_on_project_management/2009/12/agile-apprehensions.html

If you’ve been following the Scrum community in recent months, you know that there have been some big changes—a few somewhat controversial ones among them—at the Scrum Alliance. After a short stint without leadership, it appears the organization has found a new director in Lowell Lindstrom. According to the Scrum Alliance, Lindstrom has been an active part of the software industry for more than 25 years, playing various roles in the production and deployment of software. Additionally, he is a Certified ScrumMaster, Practitioner, and Trainer.

Still, this isn’t a permanent solution and the Alliance is in the process of recruiting a full-time managing director to secede Lindstrom. Board member Steve Fram is leading that charge, conducting a nation-wide search for the suitable candidate.

I’ll continue to update you as more details emerge…

I just ran across another article touting agile development’s growing popularity among enterprise-level organizations. On SearchCIO.com, executive editor Karen Guglielmo reports that, in spite of the disruptive nature of an agile implementation, more and more companies are finding it well worth the effort. Citing a survey the site conducted earlier this year with 631 participants, Guglielmo reports that “25% of 631 respondents said their organization used a rapid development methodology such as agile. Of those using it, 72% said it helped to accelerate projects, while 15% said it made it harder to manage end dates for projects. The last 13% reported no impact.” And to explain that tendency to accelerate projects, Forester senior analyst Clay Richardson explains, “Agile is better because it quickly delivers functionality to business users, maximizing adoption and input from key stakeholders through solution development. In addition, waterfall takes too long and provides less value because of lack of speed to market.”

For those of us who are already using agile to improve development efforts, this all may sound like old news. But the fact is that we’re still in the minority and, by and large, traditional management practices still dominate at most organizations. But with stories like this one, it’s encouraging to see agile moving closer to a tipping point, when it can become the standard approach to management.

Most software developers are all too familiar with a scenario in which their Product Owner or Project Manager explains that all of the features to be built in a product are equally important. That is, the manager wants them all and he wants them now. Of course, such demands are rarely rooted in reality and typically reflect the pressure placed on a manager from stakeholders and customers, not the true expression of priorities for what is to be built. Not only does such a request place an unreasonable demand on development teams, but it also creates a long-term risk known as technical debt. That is, when software is developed hastily—without regard for maintaining clean, workable code—the team ends up delivering a product with code so buggy and erratic that maintaining or expanding it becomes a frustrating job that can only be performed by a handful of developers.

In a recent article on Agile Journal, Chris Sterling discusses a form of technical debt called software debt, which he defines by the following criteria:

· “Technical Debt: those things that you choose not to do now and will impede future development if left undone;

· “Quality Debt: diminishing ability to verify functional and technical quality of entire system;

· “Configuration Management Debt: integration and release management become more risky, complex, and error-prone;

· “Design Debt: cost of adding average sized features is increasing to more than writing from scratch; and

· “Platform Experience Debt: availability and cost of people to work on system features are becoming limited.”

As you can see, software debt entails many of the same risks as technical debt and results in the same obstructed path toward sustainably editable code. So what’s the answer? How can organizations take steps to limit the frequency and degree to which software debt impacts development projects? In his article, Sterling sketches out some guidelines that will help developers and managers skirt design death: “Emphasize quality,” “Evolve tools and infrastructure continually,” “Share knowledge across the organization,” and more. However, these recommendations, in my mind, seem too soft and fuzzily outlined to keep teams from caving to management pressure or cutting corners.

For my money, no other agile framework is as capable of minimizing technical and software debt as Scrum. Its iterative and incremental nature provides regular opportunities to halt work and evaluate the progress made for quality and market relevance. Similarly, the framework and its regular work cycles can be used to prevent this kind of debt from accruing by simply creating repeated Product Backlog Items that address issues related to code quality. There’s a big difference between functional code and code that has been scoured for bugs and prepared for a seamless hand-off to the next developer who works on it.

I had heard that the latest release of ScrumWorks was being billed as the first enterprise-capable Scrum tool. (Since I’m unaware of any agile tool that can successfully scale without several modifications, it’s really the first enterprise-capable agile tool.) So I decided to watch a screencast to learn more. Now that I’ve seen what’s new in ScrumWorks Pro 4, I can say that it’s evident Danube is paying close attention to user feedback and working hard to resolve the impediments that have historically kept enterprises from successfully scaling.

One of the most important aspects of this release is “Epics,” which give users a powerful combination of deep functionality and tremendous flexibility that allows them to model shared components accurately, rather than conform to the limitations or idiosyncrasies of a tool. More specifically, the “Epics” feature gives organizations a way to pull back even farther and assess progress across multiple products and programs. Best of all, Danube achieved this functionality while remaining closely aligned to Scrum’s core principles. In fact, ScrumWorks Pro 4 and the “Epics” feature, in particular, were based on Scrum founder Ken Schwaber’s most recent book, The Enterprise and Scrum. If you think your development environment could benefit from such smart functionality, I highly recommend you take a look at this tool. You can read more about it here.

In all, it was just a great and inspiring article that shows how much a few Scrum trainers believe in what they do.

Tomas Björkholm understands this, as illustrated in his detailed investigation of the differences between two agile practices: Scrum and Kanban. In an article recently published on the Agile Journal website, Björkholm lays out the primary differences and similarities between the two methods and then weighs in on what he thinks is most valuable about each one. Certainly, they share some important sensibilities, since Kanban is most closely identified with the Lean movement, which also influenced the development of Scrum. But what differences they have make a big difference and the author astutely teases out why, for instance, Scrum’s use of iterative work cycles (i.e. sprints) is superior to Kanban’s view of work as a continuous flow. (For starters, there’s a crucial psychological factor to sprints: Scrum’s “chunking” of work enables developers to really focus on the most immediate tasks, rather than become distracted or overwhelmed by a never-ending stream of work.)

If you’d like more information on either Scrum or Kanban or would like to see an expert dissection of the two methods, I’d recommend you check out the article.

Over at InfoQ, Chris Sims reports on the notion of “good velocity,” inspired by a question Buddha Buck posed to the XP list serve: For a team of about seven, doing two-week sprints, what range of velocity would be considered ‘good’? Amazingly, Buck identifies a ‘bad’ range, explaining that a velocity of eight or less probably means a team isn’t breaking its stories down into small enough chunks.

Now, if a team’s velocity is determined by estimations, using a scale agreed upon by the team doing the estimating, how can an outsider evaluate if the team’s velocity is “good” or “bad”? Certainly, if a team’s velocity increases over time, demonstrating ongoing performance improvements, that’s good. If a team simply gets worse at working together over time, reflected in a waning velocity, then that would be clearly bad. But the notion of a standard or an acceptable range is ludicrous. Velocity is useful for the teams estimating their work—they understand what a “Small” story looks like versus an “Extra-large” one. And depending on how they choose to estimate their stories, a velocity of eight might actually be a hyper-performing team.

So, to summarize, what’s actually important with velocity is whether a team’s velocity increases or decreases. There’s no standard for performance, since there’s no standard of measurement. But a team that does more every sprint should certainly be considered to be within a “good” velocity range.

Scanlan’s reaction was to implement agile management practices. He divided his employees into small groups of roughly five or six people per team; re-imagined the floor plan so that all employees sat together for convenient collaboration; and mandated a daily Scrum meeting, when team members can report to one another. Because the team harnessed agile’s iterative and incremental approach to development, it was, significantly, able to shorten deadlines and deliver software more rapidly.

While I like to see case studies of how companies have used agile techniques to improve their own processes, there are a number of sticking points in this story. Namely, it sounds like Total Attorneys have applied a “Frankenstein” approach to agile—they’ve pulled their favorite bits from a number of frameworks and methods and built a monster out of them. Granted, this is a populist publication that is effectively introducing readers to the concept of agile project management, so we can’t realistically expect the reporter to engage the nuances of agile the way we would here on this blog, where we’re all well-versed in Scrum, XP, and so on.

How does this article strike you? Is it another victory for agile in the media? Or is it represented in a harmful way?