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!

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.

It’s funny to think that something as simple as “planning a party” could better illustrate the function and value of user stories than something within a developer’s native environment, but everybody likes parties, so this one works great. As James describes it, participants are asked to imagine that their boss is throwing a holiday party for his co-workers and, in typical boss fashion, he wants the employees to do all the work! So participants are then given a list of vague and sometimes big directives and then asked to re-write them as agile-friendly user stories. Suddenly, questions about priority (which story is most important?) and order (which story should be completed first?) start driving the conversation. Before they know it, participants have simulated the same process of prioritization a Product Owner faces when prioritizing work and planning release dates. But since the context is immediately understood, it’s somehow less daunting than considering the same factors for a software project.

So who wants to plan a party?

DZone’s most recent Refcard departs from its usual technical focus for a discussion of the agile project management framework, Scrum. It was written by a real expert on the subject, Michael James, who is a Certified Scrum Trainer for Danube, the company that makes the agile management tool, ScrumWorks Pro. Many people have a hard time articulating what Scrum is or how it differs from traditional project management, but James outlines Scrum’s roles, meetings, and artifacts in a way that is concise and easy to understand. It’ll be mostly review for those who already work in a Scrum environment, but, even then, I suspect veteran Scrum practitioners will recognize how well-organized James’ overview is and want to use it to help new team members smoothly transition into life on a Scrum team.

I’ve posted it for download below. Take a look. I think you’ll find it to be very valuable.

Scrum_Refcard.pdf

My two cents? Personally, I tend to think that a Product Owner should not divide his or her attention. If the Product Owner is having a hard time finding enough to do, chances are he or she could take a more hands-on role with the team. And given that there is considerable disparity in terms of authority between the team and the Product Owner, I think that Product Owners should be selected from outside of the team, not appointed from within.

Here’s CST Dan Rawsthorne echoing my sentiments on the topic: “I always have a simple answer to ‘who will be your product owner.’ I just ask ‘who are you holding accountable for success? Who has the bullseye on his back? That’s your product owner.’ In my experience, the PO is usually anointed from the outside.”

If you don’t agree with my take on the Product Owner, there are plenty of vocal Scrum practitioners ready to take your side on the Scrum Development list.

Read more on InfoQ (http://www.infoq.com/news/2009/02/product-owner-one-person) or follow the whole thread here: http://groups.yahoo.com/group/scrumdevelopment/message/36389.

This problem gets even trickier if your Product Owner is also your Boss with a capital B. For smaller organizations, it’s not uncommon that the president or CEO would also act as a Product Owner. When that happens, it might be even harder to ask that he or she limit her involvement in the Scrum team. But the same rules apply. For Scrum to truly facilitate hyper-performing teams, those teams must be empowered to decide how they pursue their work. After all, that responsibility is accompanied by a sense of ownership over its success and a commitment to realize that success that is shared with the rest of the team. Besides, when a team is experienced at making tough decisions to get results, that frees up the Product Owner—and, in this scenario, president or CEO—to think about big-picture strategy. In that sense, Scrum is a sensible framework because it acknowledges that the Product Owner can’t—and shouldn’t—have his finger in every aspect of the business. Instead, Scrum recognizes the necessity of distributing both responsibility and authority.

Because Scrum asks that teams self-organize, that means that they must decide among themselves how to accomplish sprint goals. Invariably, not everyone on the team will agree as to what the best route to success is. When that happens, the team must reach a decision that everyone can live with, working toward a compromise between the team’s most extreme perspectives.

Unlike authoritarian decision-making, this process can take time. Instead of a single manager dictating a decision, the team must take into account a wider range of ideas and opinions and negotiate a middle ground that best addresses the problem. By considering so many points of view, the team is essentially consulting a wider range of knowledge and experience than a single decision-maker possibly could. It’s a process that certainly takes longer, which has led to some criticizing consensus-based decision-making as inefficient. But in reality, this approach yields decisions that are better informed and, consequently, drive results.