Free Project Management Software

It seems to me that the true test of an individual’s belief in what he or she does is whether or not they would do it for free. Well, if you’ve ever wondered about how much a Scrum trainer believes in Scrum, InfoQ has just published a story on how a handful of trainers have put their money where their mouths are. According to agile reporter Mark Levison, a number of Scrum trainers have decided to make Scrum training, including ScrumMaster Certification, available to folks who could not otherwise afford it. CST Tobias Mayer has launched a program called WelfareCSM, which does just that. Likewise, three CSTs—James Coplien, Danube’s Dr. Dan Rawsthorne, PhD, and Alan Cyment—recently traveled to Serbia to provide free training to professionals who live in an area that doesn’t see too many CSM courses offered. In support of that effort, the Scrum Alliance even covered travel and other expenses.

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

Most forward-thinking software organizations have already accepted that they need to be agile in order to compete in a market whose evolution is accelerating faster than ever before. Of course, being “agile” is a fairly vague descriptor. However, those readers who have successfully implemented agile management and engineering techniques at their organization know that for the vagary embedded in the phrase “agility,” real organizational change occurs through very specific activities. That is, agility entails much more than simply declaring one’s self to be agile. Instead, true agility is the result of dedicated observation of agile values and the committed practice of its processes.

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.

If you’ve been reading Free Project Management Software lately, you know that we just wrapped up a blog series on criteria to consider when evaluating agile tools. Well, if your team in fact uses agile methods or Scrum in particular, then this post will also be of interest.

The website DZone regularly produces “Refcardz,” which are basically brief reference guides on need-to-know topics for developers. DZone’s newest one is dedicated to an introductory discussion of Scrum and authored by Danube Certified Scrum Trainer Michael James. Organized for quick, at-a-glance referencing and tackling the fundamentals of Scrum (roles, meetings, artifacts, etc.), James’ Refcard on Scrum provides an experienced, no-nonsense take on the framework. Yes, there’s a lot more involved in doing Scrum correctly than could possibly be contained in a document as succinct as this one, but, for a free resource, this is loaded with good stuff.

Did I mention it’s free? Download it below.

Scrum_Refcard.pdf

Late last month, the Software Education SDC was held in Melbourne, Australia and Wellington, New Zealand. During the conference, Ivar Jacobson—who pioneered Use Cases, UML, and RUP—stated that agile needs to get “smarter.” Key to his criticism was the software industry’s tendency to jump on fashionable trends. To illustrate his point, he broke down the industry’s techniques du jour for the past 15 years like this:

• Fifteen years ago it was all about OO
• Ten years ago it was about components, UML, Unified Process
• Five years ago it was about RUP and CMMi
• Two years ago it was about XP
• Today it is about Scrum

Longtime readers know I’m an advocate of Scrum, which is the agile method that my team uses. I really see how it improves processes and gets our team to do things we didn’t think we could, so I hate to think of it as a fad. Certainly, its popularity has skyrocketed in the last year or two, but isn’t that due to its real potential to transform the way organizations approach software development? And aren’t all of these “flavors of the month,” as Jacobson suggests, part of a more macro-evolution in software development that extends well beyond agile? That is, as we discover new ways to work more effectively—or “smarter,” as Jacobson says—those new ways naturally displace the less effective methods that preceded them.

So is the history of software development over the last 15 years really a matter of faddish techniques and processes going in and out of fashion? Or is it simply a necessary evolution toward optimal working methods? You can read all of Jacobson’s concerns and suggested solutions at InfoQ.

Over at Agile Journal, Dean Leffingwell has posted the first of a three-part series on the role of the Product Owner within an enterprise-sized agile organization. This seems like a particularly valuable subject, given that it examines the intersection of a pair of hot topics in the agile community: Not only does it address the precarious endeavor of scaling agile throughout an enterprise, it also focuses on how the Product Owner can help make that process a smoother, more successful transition. Leffingwell is writing from a point of experience—having trained thousands of CSMs at large-scale installations—so when he claims that none of the professionals he has trained would ever consider going back to their previous methods of development, it’s a compelling argument for agile.

In this opening article, he stresses the need for organizations to develop a nuanced Product Owner role. That is, Leffingwell suggests that simply following the role’s prescriptive responsibilities might undercut its potential. While he cites Scrum founder Ken Schwaber’s definition of the Product Owner as a solid starting point, he quickly expands the role’s functions to include:

• Setting objectives for the Sprint (or iteration)
• Prioritizing and maintaining the backlog
• Participating in the Sprint planning meeting
• Elaborating stories on a just in time basis with the team
• Accepting stories into the baseline
• Accepting the Sprint
• Driving release planning

For anyone who has served as a Product Owner, whether in an enterprise or a smaller organization, this list of responsibilities will look very familiar. Still, those of you may be thinking it doesn’t quite capture the extent of a Product Owner’s participation. For Leffingwell, that’s because Product Ownership at enterprises tend to fall into two distinct categories. On the one hand, the Product Owner exists outside of the team, interfacing with clients and focusing on visionary activities such as forecasting and identifying opportunities within a thrashing market landscape. On the other, the Product Owner is very much part of the team, working with them to realize the customer’s vision and provide guidance when needed. Rather than ask customer-facing Product Owners to take on more technical responsibility within the team or, conversely, ask technical managers to take on more customer-facing activities, he suggests that enterprise-level installations require both kinds of Product Owners. After all, they represent distinctly different skill sets.

For the most part, I tend to believe that the Scrum framework is flexible enough to scale, without making drastic amendments to the framework itself, but Leffingwell’s point is well taken. What do you think? How do you deal with these kinds of issues at your organization?

You can read Leffingwell’s entire post here: http://www.agilejournal.com/articles/columns/articles/1225-the-product-owner-in-the-agile-enterprise

For many Scrum teams, “work” is what’s documented in the Backlog. If you’re like me, you can’t help but hear agile guru Jeff Sutherland’s famous remark that, “If it’s not in the backlog, it doesn’t exist” in your mind. But that’s not quite true. Even Scrum teams have work they should commit to as repeatable, maintenance-oriented tasks that occurs each and every sprint. One of the most important of these activities is backlog grooming. Ken Schwaber recommends that teams devote five percent of their time each week to this activity (about two hours per week). In spite of this mandate from the top, many Scrum team members continue to resist. The perception is that any work that deviates from one’s primary job function is extraneous . So software developers, for example, often hold fast to the idea that their time should be only spent writing code.

But here’s the thing: It’s all work. The work a team does each sprint to ensure that it can hit the ground running on its next set of sprint goals is no less essential to the team’s sustained performance. Even if it forces a developer to stop coding for two hours each week, what that “downtime” enables outweighs whatever code could have been written in the same amount of time. In short, this activity is like a pit stop for a racecar: A brief preparatory break that enables the team to keep going at full speed.

If team members are still reluctant to acknowledge grooming as part of their regular workload, then I’d suggest creating a repeatable story that can build this maintenance into the backlog each sprint.