In a blog post on the SDTImes website (“Agile Making ALM Teams Work Faster, More Open”), Jeff Feinman takes a moment to share one aspect of a larger article he’s working on about agile life-cycle management (ALM), but that one aspect is a big one. According to Feinman, as he’s surveyed dozens of ALM companies about how they deliver their processes, ALL of the companies he’s talked to report that “100% of their customers are at the very least thinking about adopting agile processes.”

Though agile has soared in popularity over the past year or two, this is still a staggering update, illustrating just how widely agile adoption truly is. Still, one enduring impediment to adoption is the desire for organizations to implement a tool, rather than a process. Anders Wallgren, CTO of Electric Cloud, explains: “Part of what takes a thing like agile some time to get adopted is, I think, naturally, we want to buy a tool, not a process. So if I hear about this thing called agile, I’ll say well, ‘Where do I buy the agile software package?’ It’s a little difficult to get people to change their processes.”

Of course, some tools are designed specifically to reinforce that process. As I’ve mentioned here before, my team manages its projects using Scrum. Because Danube’s tool ScrumWorks Pro was created with the framework in mind, it complements my team’s activities perfectly, while giving new team members a guide rail to help them follow Scrum’s processes.

Longtime readers of this blog know that I’m a big proponent of Danube’s project management tool ScrumWorks Pro. The company released a major release back in August (ScrumWorks Pro 4) that added some exceptionally flexible program management capabilities to the tool, but, since then, they’ve been issuing point releases at a swift clip. One of the reasons for this is their new Community Portal, a forum where ScrumWorks Pro users can communicate directly with the tool’s Product Owner and Development Team as well as one another. There, users can suggest features to be added in future releases, vote on other users’ ideas, or simply post a question they need help with. When I first heard about it, it sounded like a great idea—a way to create a true community of Scrum users who can work together to continually improve the tool. But now the fruits of Danube’s labor are starting to show. For example, if you head here, you can actually see what features have been implemented in the tool based on the conversations generated on this forum. Very cool.

What I especially love about this concept is that it actually shows how Danube uses Scrum and agile processes and values to shape ScrumWorks Pro. For instance, the Portal acts as a great information radiator—any user can quickly see what’s being worked on and who’s discussing what ideas. Likewise, it offers the Development Team an abbreviated feedback loop, so they’re always calibrating their product direction based on the emerging needs of customers. It makes me happy to see a Scrum company putting its money where its mouth is!

If you’re a seasoned agile practitioner, you’ve likely got a whole treasure trove of best practices at your disposal. But if you’re just getting started and trying to make a clean break with traditional management practices, you might benefit from this list of “26 Hints for Agile Software Development” compiled by Keith Swenson. They range from the general/philosophical (“Eliminate waste”) to more granular, engineering-oriented advice (“Never add a data member before it is needed in a use case”). For the uninitiated, this list covers a lot of the bases. Check it out!

On this blog, we spend a lot of time dissecting the details of agile project management, even arguing over fine shades of distinction. But in an InfoQ article titled “Agile’s ‘One Essential Ingredient,’” Mike Bria reports on Mark Schumann’s wide-angle view of agile. Considering the single most important ingredient to success with agile, Schumann suggests that, beyond particular engineering techniques or even a specific methodology, the one thing that enables agile’s benefits is a legitimate shift in mindset. Certainly, this is something that many agile practitioners have already rallied around: For agile management to succeed at an organization, its practitioners must fully understand and embrace the philosophical changes it entails. Simply changing job titles or going through the motions won’t cut the mustard.

But Schumann goes on to explain that this cultural buy-off not only needs to occur at the team-level, but among managers, as well. While the three attributes of great agile teams—“correction, imagination, and trust”—are essential for teams to succeed, he argues that it’s even more important that management exhibit these traits, as well. From there, Schumann whittles agile’s most essential ingredient to “humility,” writing:

“Trust means you have to give up Control. A lot of it.
Imagination means you will have less Certainty.
Correction means you have to acknowledge that you never had Perfection to begin with.

“…the organizations that do well with Agile software development – or any other kind of Agile work for that matter – are the ones that can cope with losing Control, Certainty, and the assurance of Perfection.”

At the heart of the matter, Schumann is describing a general attitude of openness, in which management does not necessarily presume to know the right answer or best course of action. Instead, they remain open to the possibility that someone closer to the problem (that is, a developer) might have more insight into how to solve it. This is in line with agile’s use of iterations to constantly assess how to best respond to emerging conditions. Success is not the result of a prescriptive process, but, rather, a process of remaining observant and critical in order to react to reality.

You can read Schumann’s thoughts in full here, but I’m curious to hear from you readers. Would you agree that humility and meaningful support of agile from management is the factor that makes or breaks agile success?

Lean has been a popular topic on this site lately, so I wanted to direct readers to a free report that Forrester Research recently published to coincide with their annual Business Technology Forum. This year’s theme is “Lean: The New Business Technology Imperative,” which focuses on how Lean can help organizations reduce waste, create value for customers, and help them respond more nimbly to emerging conditions. Take a look at the free analyst report here.

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.

If you’ve ever had to convince a manager of the value of agile programming techniques, such as test-driven development and pair programming, you know what an uphill battle that can be. But Mike Bria at InfoQ has just posted an article titled “How TDD and Pairing Improve Production,” which takes those anti-agile attitudes to task. In response to such common criticism of pair programming as “twice as many people writing half as much code,” Bria turns to Mike Hill who identifies the key to boosting productivity as a matter of improving internal quality, citing the following three proof points:

1. “Because internal quality and external quality are not the same things.

2. “Because the biggest single determinant in today’s production is the quality of yesterday’s production.

3. “Because typing is not now and never has been the bottleneck in writing code.”

So what steps can development teams take to ensure that their internal code maintains a high level of quality? Again, Hill provides the answer with three more things to consider:

1. “Write a microtest that fails before you change any code.

2. “Adopt a “no-pair no-keep” agreement.

3. “Establish a shared understanding of internal quality.”

You can take a look at the entire article here.

Read the entire review here: http://www.agilejournal.com/articles/17-articles/1746-featured-book-the-art-of-lean-software-development-by-curt-hibbs-steve-jewett-and-mike-sullivan

Just as the Agile Manifesto identified a set of priorities for a new approach to software development, this manifesto further refines the criteria. As they explain it, software should not only be working, but well-crafted; development should not just respond to change incrementally, but also add value incrementally; individuals and interactions may be privileged, but they need to emerge as a cohesive community; and customer participation is not enough, it needs to result in “productive partnerships.”

I’m sure that devout agilistas would regard this development as consistent with agile’s commitment to inspect and adapt. But are the distinctions made here valuable or do they just amount to semantic quibbles? Personally, I see some of the language as moving closer toward a precise articulation of what the original manifesto sketched out, but, at other times, it seems like splitting hairs. What do you think?