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/.

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

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.

Though traditional project management and Scrum have long been viewed as antithetical ways of working, that’s not quite right. It would be more accurate to say that Scrum simply responds to and refines the shortcomings of traditional management practices. Still, as Scrum and other agile methods have continued to grow in the past few years, many PMPs have begun reassessing Scrum and agile to see what aspects of those methods it can utilize. On the PMI website, they’ve just run a short interview with an individual who straddles both worlds: Jimi Fosdick, who is both a PMP and a CST (certified Scrum trainer). According to him, it’s still possible for traditional project management and Scrum and agile to coexist. Still, he’s quick to point out that there are major challenges. Of those, he cites the following as the most irksome:

“Organizational Structure: Companies aren’t usually set up to handle the way the work is done in scrum and agile–and that’s a very difficult thing to change.

“Corporate Culture: Scrum is built on the principles of self-organization and self-management. So the development team doesn’t really have a boss or a manager telling them what to do. And that’s very scary for a lot of organizations. There’s a prevailing belief–left over from the scientific management of the 1950s and 1960s–that unless you’re watching what your people are doing, they won’t complete the task at hand.

“False Assumptions: Many of the policies and progress metrics in place in organizations and the artifacts and reporting required, are often counterproductive and run contrary to scrum. Some tasks–like needing sign-off on a full requirements document before development can start–interferes with the ability to do something in an agile way.”

You can read more here: http://blogs.pmi.org/blog/voices_on_project_management/2009/12/agile-apprehensions.html

If you’ve been following the Scrum community in recent months, you know that there have been some big changes—a few somewhat controversial ones among them—at the Scrum Alliance. After a short stint without leadership, it appears the organization has found a new director in Lowell Lindstrom. According to the Scrum Alliance, Lindstrom has been an active part of the software industry for more than 25 years, playing various roles in the production and deployment of software. Additionally, he is a Certified ScrumMaster, Practitioner, and Trainer.

Still, this isn’t a permanent solution and the Alliance is in the process of recruiting a full-time managing director to secede Lindstrom. Board member Steve Fram is leading that charge, conducting a nation-wide search for the suitable candidate.

I’ll continue to update you as more details emerge…

I just ran across another article touting agile development’s growing popularity among enterprise-level organizations. On SearchCIO.com, executive editor Karen Guglielmo reports that, in spite of the disruptive nature of an agile implementation, more and more companies are finding it well worth the effort. Citing a survey the site conducted earlier this year with 631 participants, Guglielmo reports that “25% of 631 respondents said their organization used a rapid development methodology such as agile. Of those using it, 72% said it helped to accelerate projects, while 15% said it made it harder to manage end dates for projects. The last 13% reported no impact.” And to explain that tendency to accelerate projects, Forester senior analyst Clay Richardson explains, “Agile is better because it quickly delivers functionality to business users, maximizing adoption and input from key stakeholders through solution development. In addition, waterfall takes too long and provides less value because of lack of speed to market.”

For those of us who are already using agile to improve development efforts, this all may sound like old news. But the fact is that we’re still in the minority and, by and large, traditional management practices still dominate at most organizations. But with stories like this one, it’s encouraging to see agile moving closer to a tipping point, when it can become the standard approach to management.

Most software developers are all too familiar with a scenario in which their Product Owner or Project Manager explains that all of the features to be built in a product are equally important. That is, the manager wants them all and he wants them now. Of course, such demands are rarely rooted in reality and typically reflect the pressure placed on a manager from stakeholders and customers, not the true expression of priorities for what is to be built. Not only does such a request place an unreasonable demand on development teams, but it also creates a long-term risk known as technical debt. That is, when software is developed hastily—without regard for maintaining clean, workable code—the team ends up delivering a product with code so buggy and erratic that maintaining or expanding it becomes a frustrating job that can only be performed by a handful of developers.

In a recent article on Agile Journal, Chris Sterling discusses a form of technical debt called software debt, which he defines by the following criteria:

· “Technical Debt: those things that you choose not to do now and will impede future development if left undone;

· “Quality Debt: diminishing ability to verify functional and technical quality of entire system;

· “Configuration Management Debt: integration and release management become more risky, complex, and error-prone;

· “Design Debt: cost of adding average sized features is increasing to more than writing from scratch; and

· “Platform Experience Debt: availability and cost of people to work on system features are becoming limited.”

As you can see, software debt entails many of the same risks as technical debt and results in the same obstructed path toward sustainably editable code. So what’s the answer? How can organizations take steps to limit the frequency and degree to which software debt impacts development projects? In his article, Sterling sketches out some guidelines that will help developers and managers skirt design death: “Emphasize quality,” “Evolve tools and infrastructure continually,” “Share knowledge across the organization,” and more. However, these recommendations, in my mind, seem too soft and fuzzily outlined to keep teams from caving to management pressure or cutting corners.

For my money, no other agile framework is as capable of minimizing technical and software debt as Scrum. Its iterative and incremental nature provides regular opportunities to halt work and evaluate the progress made for quality and market relevance. Similarly, the framework and its regular work cycles can be used to prevent this kind of debt from accruing by simply creating repeated Product Backlog Items that address issues related to code quality. There’s a big difference between functional code and code that has been scoured for bugs and prepared for a seamless hand-off to the next developer who works on it.

I had heard that the latest release of ScrumWorks was being billed as the first enterprise-capable Scrum tool. (Since I’m unaware of any agile tool that can successfully scale without several modifications, it’s really the first enterprise-capable agile tool.) So I decided to watch a screencast to learn more. Now that I’ve seen what’s new in ScrumWorks Pro 4, I can say that it’s evident Danube is paying close attention to user feedback and working hard to resolve the impediments that have historically kept enterprises from successfully scaling.

One of the most important aspects of this release is “Epics,” which give users a powerful combination of deep functionality and tremendous flexibility that allows them to model shared components accurately, rather than conform to the limitations or idiosyncrasies of a tool. More specifically, the “Epics” feature gives organizations a way to pull back even farther and assess progress across multiple products and programs. Best of all, Danube achieved this functionality while remaining closely aligned to Scrum’s core principles. In fact, ScrumWorks Pro 4 and the “Epics” feature, in particular, were based on Scrum founder Ken Schwaber’s most recent book, The Enterprise and Scrum. If you think your development environment could benefit from such smart functionality, I highly recommend you take a look at this tool. You can read more about it here.