Free Project Management Software

There is an interesting discussion on the Scrum Alliance Google groups about Advice Needed for Difficult Developers. According to Anita, the group member that raised the issue, she is finding the developers on her team very combative, unprofessional and rude. She is finding that they say they want to “use Scrum” but as the ScrumMaster is finding difficulty getting the team on the same page and getting them to work collaboratively together.

Respondents have given a lot of helpful advice. One respondent said that he thinks it is effective to give people feedback on how they are behaving and points us to Esther Derby’s blog. Esther is an agile coach and wrote an interesting blog post on Why Group Dynamics and Interpersonal Skills Matter. A few of the interesting points that Esther makes are:

“High-tech companies succeed by out learning and out innovating the competition. Group dynamics directly the affect the ability of a team to think, learn, and innovate together.”
• “Groups that avoid conflict won’t be able to face tough issues or handle the creative conflict that generates new ideas.”
• “Groups that are highly competitive won’t share ideas and build on other’s ideas. People won’t share the credit for success, further decreasing the chance for creative collaboration.”
• “Groups that defer to a person of higher status will miss many good ideas, and fail to tap and develop the talents of the entire group.”
• “Groups that haven’t learned to work well together will take the first workable solution to avoid unsatisfying and uncomfortable interactions.”
Source: Esther Derby Blog

Sometimes games can be an effective way to explore how teams solve problems together, how they innovate and how they deal with pressure, and gives a ScrumMaster or agile coach clues as to how they can help them learn and what they will need to be successful with Scrum. Angela Druckman, a CollabNet CST and agile mentor, describes in her blog the “Ball Point Game” and some of the success she has achieved with it.

Continuous learning and coaching is also important if your team is feeling stuck. For free webinars about Scrum and Agile visit http://blogs.danube.com/scrum-webinars/.

Typically HR practices are rooted in popular misunderstandings of behavioral psychology and what motivates individuals in a work environment. Studies of human motivation reveal typical practices such as micromanagement and performance appraisals are counterproductive in the long run. When filling Scrum roles, HR departments and hiring managers will often overemphasize credentials and skills and give insufficient weight to the chemistry of the team and letting the team play a key role in the hiring process. Because Scrum is based on teams that are empowered and self-organizing, oftentimes, employees that appear negative under the restrictions of a forced hierarchy or traditional management can often excel when set free on the right Scrum team because they are often suppressed leaders.

Within organizations using Scrum there can be some confusion as to how people management aspects such as grievance/disciplinary procedures, annual reviews etc should be handled. (See this discussion on Google groups…http://groups.google.com/group/scrumalliance/browse_thread/thread/42c97a2651aa570d)

When we refer to Scrum teams as being “self-managing” teams we do not mean that team members can decide to give each other a raise, or fire another team member. This is normally considered an HR or management task. However, for a Scrum implementation to be successful and for an organization practicing Scrum to be a truly extraordinary organization, there must be a collaboration between HR and Scrum teams when making Scrum organizational decisions. If you are interested in learning more about HR’s role in the process and how HR can work with Scrum teams to be successful, check out this article by Michael James, a CollabNet Certified Scrum Trainer and Coach: http://www.sendspace.com/pro/dl/vzocgh

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