Free Project Management Software

Book your tickets for Orlando, FL! Due to the recent flooding in Nashville, TN the Agile Alliance announced that Agile 2010 is being moved from Nashville to Orlando. The event is being relocated to the Walt Disney World Swan and Dolphin hotel in Orlando, FL. The dates will remain the same – August 9th -13th – which means that speakers and schedules will remain the same. Many of us were looking forward to going to Nashville and staying at the Opryland hotel. However, according to one recent news report the historic Gaylord Opryland Hotel was significantly damaged in the flooding and might not reopen until the end of the year. Given the uncertainty of when a restoration of the hotel would be completed, show organizers decided to move quickly to identify new locations that could accommodate 1600 agile enthusiasts on such short notice. Not an easy task, but they did it!
If you’re planning to attend it’s not too early to register. Attendees are encouraged to register now to obtain the Super Early Bird and Early Bird rates. For more information or to register online, visit (http://agile2010.agilealliance.org/register.html). Should you require registration assistance, or have any questions, please contact Michelle Wilson at Elastic Communications & Events at agileregistration@elasticevents.com or 905-281-0555, Ext. 113. In its ninth year, Agile 2010 is the leading international conference on agile methods in software development, bringing together many disciplines in the fields of information systems and software development to foster the exchange of fresh ideas and best practices.

There’s an amusing article called “How I Stole an Office and Fixed our Daily Scrum” by Aaron Conoly on the Scrum Alliance website which describes how he improved their daily Scrum meetings. One of his tips for improving the daily scrum was to kick the boss out of the meeting. Once that happened people started working as a team, sharing information and getting things done! Imagine that! Is that what we call “self-organizing” in “Scrum”?

Failing to conduct daily Scrum meetings are often times a point of failure for teams moving toward agile transformations. Some teams see meeting everyday to be cumbersome if they are distributed, on different timezones, or too large. However, the “daily scrum” is the heartbeat of Scrum and critical to the success of using a scrum framework in software development. Other guidelines Aaron recommends to make the daily scrum successful are to hold the meeting early in the day, time box it to no more than 15 minutes, and have everyone attend and participate. Oh yeah – and don’t invite your boss to the meetings!

At InfoQ, reporter Amr Elssamadisy recently posted an article considering technical debt. Most teams—especially those who work with legacy systems—understand the dangers of technical debt. In short, when the quality of code suffers for the sake of expedited development, the team accrues what is called “technical debt.” Ideally, the team “repays” this debt by fixing sloppy coding and bugs before writing more code. So, to extend the budgeting metaphor, a development team should strive to “live within its means,” addressing technical debt when it accumulates, rather than moving forward and amassing more. In the InfoQ post, Elssamadisy considers whether technical debt is a technical problem or, as he asserts, a symptom of a larger organizational problem. That is, could technical debt be prevented by imposing more rigorous coding standards or utilizing agile development techniques, like test-driven design? Or is the fact that this debt is primarily visible to the development team the more formidable threat?

I’d love to hear what you think about this issue. Please share your thoughts in the comment section. If you’re looking for further reading on the topic, I’d highly recommend you download the whitepaper “Technical Debt and Design Death” by CSTs Michael James and Kane Mar.

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.