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

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.

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.

Scrum_agile_RFP_guide_FINAL.xls

Enterprise Scalability

• Is your tool an industry standard? How many users use your tool?
• Can users be managed via enterprise directory authentication such as Active Directory and LDAP?
• Are integrations with common bug-tracking applications available?
• Does the tool have the ability to support distributed teams?
• Has your tool been deployed for 500+ users on a single instance at a single customer site? 1,000+ users?
• Can you provide three large-customer references? Please list three multi-hundred user installations, approximate number of users, and primary contact.

Data and Security

• Do you support automated and manual backups?
• Are client-server communications encrypted with SSL?
• Do you support encrypted enterprise directory authentication such as LDAPS?
• Do you offer a technology escrow option in case adversity befalls your organization?
• How is programmatic access to the data provided in your tool?
• Does the tool have a web services API for data access and integration purposes? Please describe the scope of the API.
• If your tool is remotely hosted, please provide a detailed outage history.
• If your tool is remotely hosted, please provide uptime SLA.
• If your tool is remotely hosted, how often do you have scheduled maintenance downtimes?

Support

• Describe your technical support options.
• How many times per year do you release?
• Can customers choose when to upgrade?
• Does the tool offer an in-depth, online product manual?
• Is documentation built into the tool?
• Can technical support be accessed directly through the tool?
• What percentage of features released were originally requested by users?
• What is the process for requesting features?

Team Communication and Collaboration

• Does your tool provide for Sprint Burndown charts?
• Does your tool provide teams a way to load balance work amongst team members?
• Do you provide a software equivalent to a physical task board?
• Does the tool contain a personalized/customizable view of each individual’s tasks across multiple products?
• Does the tool enable customizable notifications?

Reporting

• Are reports based on User Stories and Velocity, or by summing task-level detail?
• How are release dates forecasted?
• Does the tool provide an exhaustive audit/change log?
• Does the tool contain an easily accessible executive/stakeholder “traffic light”-style progress indicator?
• How can reports be delivered to managers and stakeholders (external of the tool)?
• Does the tool have the capacity to report specific changes within a sprint?
• Does the tool include an overview of a team’s tasks, divided by individual?
• Does the tool include non-agile metrics, such as individual burndown charts or gantt charts?

Installation/Administration

• Describe the installation/deployment process.
• Are there any hardware specification recommendations?
• Does the tool offer support for multiple user types?
• Can I define multiple administrators to spread the administrative load?
• Can projects/products have local administrators?
• Does the tool offer role-based permissions? How granular are the role permissions?
• Does the tool offer role templates that apply to multiple products/projects?

Training

• Do you recommend product training for new users?
• Is training available for updates?
• Can we look to your organization for training on agile and Scrum in general?

Agile Compatibility

• Is your tool designed exclusively for the Scrum method or is it an all-in-one tool?
• Is the tool capable of capturing requirements as User Stories/Backlog Items?
• Can Product Backlog Items be easily prioritized (e.g., with drag-and-drop)?
• Does the tool enforce a strict priority ordering for Product Backlog Items?
• Is there a way to capture and expose impediments blocking the team/organization?
• Are your metrics based on the User Story/Backlog Item level as opposed to the task level?
• Can effort units for User Stories/Backlog Items be customized?
• Is there a clearly separated Product Backlog and Sprint Backlog? Are both of these aspects visible from the same screen?
• Can Product Backlog Items be moved into the Sprint Backlog using drag-and-drop?
• Does the tool offer a way to print requirements and tasks to cards for use on physical task boards?
• How does the tool function as an information radiator to users and non-users alike? Can you publish data out to URLs for consumption by anyone on the network?
• How does your tool handle scaled agile scenarios with multiple teams working against a single release or backlog?
• Does your firm demonstrate a clear understanding of Scrum principles? Do you have in-house expertise (not including partners) to provide service offerings around Scrum and agile such as Certified ScrumMaster training?

Release Planning and Tracking

• Is the tool capable of creating custom releases and release dates? Can reports be filtered and customized by release?
• Can releases be prioritized amongst other releases?
• Does the tool contain a release forecasting capability based on empirical metrics like Mike Cohn’s “Alternative Burndown Chart”?
• How does your tool handle the categorization of work? Do you use tags/themes or a nested hierarchy and why?
• Does the tool track progress for high-level requirements (Epics)?
• Does the tool permit release reporting across multiple teams?
• Does the tool permit release reporting across multiple products?
• Is it possible to filter your release backlog to isolate a specific feature or set of features for a more focused prioritization or feature decomposition?
• Does the tool allow users to assign business valuations to User Stories/Backlog Items to better inform release planning?

Usability

• Please describe how the interface utilizes drag-and-drop.
• Please describe the tool’s time-saving interface features such as keyboard shortcuts.
• How are “bulk” operations performed?
• How do I copy and paste commonly recurring tasks?
• How does the interface allow for customized screen layouts?
• Does the tool include a “search” feature?
• Does the tool offer in-line editing?
• How does the tool support printing?
• Can users attach files to User Stories/Backlog Items? Is it restricted to specific file types?

For the next week, I’ll post a chunk of criteria for you to take a look at. But be sure to check back later this week, when I’ll post a downloadable Excel document of the entire RFP for you to use at your organization.

For the first installment, here are the sections on Platform and Deployment, Licensing and Cost, and Product Evaluation.

Platform and Deployment

• For security purposes, is your tool provided as an on-premise install?
• What operating systems do you support on the server-side?
• What operating systems do you support on the client-side?
• Please list any prerequisite software packages your tool relies on.
• For an on-premise deployment, what server-side software prerequisites are needed to run your tool?
• What database platforms do you support?

Licensing and Cost

• Please describe the licensing models you offer (subscription, perpetual, concurrent/floating).
• Are the license fees different for an on-premise vs. hosted deployment?
• What are the licensing fees?
• What volume licensing discounts are available?
• If you offer a perpetual license model, describe your support/maintenance contracts.
• Do you charge extra for certain components, modules or add-ons? Please detail any fees for add-ons.
• Please break down the total cost of ownership (including support contracts, if applicable) at year one, three, and five.

Product Evaluation

• Is a time-limited free trial of your product available? Are there limits on the number of users I can trial with?
• Can I try your tool with my data or do I need to use sample data you provide?
• For security reasons, is your trial available as an on-premise install?
• In addition to your commercial tool, is there a freeware edition of your tool? Is the freeware edition limited in some way (e.g., number of users, projects, teams, etc.)?
• Can data from a freeware or trial edition be preserved and transferred to a commercial upgrade of the tool if we decide to buy it?

The company has seen more than 10,000 software professionals and development teams register for ScrumWorks Basic during January and February alone, marking a 60 percent increase in unique registrations for Basic compared to the same time period last year.

I’m always happy to see the tool that my team uses grow its user base, but this dramatic spike in usage got me thinking. Is this uptick in registrations simply a reflection of the current economy? That is, with organizations scrambling to make cost-cutting changes, are more teams turning to freeware solutions? Or is this news indicative of the arrival of Scrum within the agile landscape? Or maybe it’s a combination of both. Certainly, it’s a testament to the value of ScrumWorks Basic, but what do you think? Have you or your teams been switching to freeware solutions of late? What do you make of this trend?