program selection system

Salesforce.com took a big bang approach to implement a SCRUM method, with huge success. This meant big changes to how Product Managers work, how we interact with the team, and manages dependencies between teams.

No more 200 page functional specs, no more waiting 12-18 months before features got into customers hands. No more changes to the release dates – how do we survive?

LANDesk Software started developing their shrink wrapped products using a variant of extreme programming (XP) in 2002. They made significant changes to a large legacy system, but wanted to communicate better with customers. They expanded their Human Factors team to focus on this problem. The Human Factors team developed personae to integrate the user into the development process.

Utilizing pair programming in the classroom requires specific classroom management techniques. We have created eleven guidelines for successfully implementing pair programming in the classroom. These guidelines are based on pair programming experiences spanning seven years and over one thousand students at North Carolina State University. In Fall 2007, pair programming was adopted in the undergraduate human-computer interaction (HCI) course at Virginia Tech.

Code71, Inc. is a Web 2.0 solution and service company. Our target market is start-ups, small-businesses and non-profit organizations. We use on-shore + off-shore model using Scrum to deliver our projects. Our off-shore office is in Dhaka, Bangladesh.

To support an agile methodology effectively on an enterprise scale, a lightweight release framework is highly useful in empowering small self-organizing teams while “optimizing the whole” of the product you are focused on delivering. Interestingly enough, we found that the absence of one can actually inhibit agility and avoidable ambiguity, in an environment where there is a high degree of unavoidable ambiguity. Find out how we created a lightweight release framework and enabled even greater agility in the organization!

The creation of excellent user experiences often appears to be a forgotten goal in the software development world. This paper discusses the use of a concrete method, Contextual Inquiry, which leads to insights that will help development teams create experiences and interfaces that match user needs and expectations. This method encourages Agile team members to see the world from the users’ perspective by working directly in the users’ context.

This presentation outlines one team’s shift from the traditional waterfall methodology to an agile approach for web development. The transformation occurred over the course of an advising system project at The Ohio State University. Using the five stages of grieving as a metaphor, we will describe how the team moved from denial that waterfall was failing to acceptance that agile practices would be the best way to deliver the mission-critical application. Ultimately, the entire team re-envisioned itself, transformed its business practices, and evolved into a significantly more agile shop.

For Info Tech, Inc., the transition to Agile practices three years ago lead to a change in the way we collaborate and contract with our long term, mostly government customers. Our evolution covered Time and Materials (T&M) contracts, a Hybrid of T&M and Fixed Price and most recently a Fixed Price, Fixed Scope, Fixed Schedule contract that supports Agile development. Our goal has been to meet our customer’s needs for predictable results while maintaining our commitment to agile practices.

You’re the executive-sponsor of your division’s foray into agile. It was successful with the first development team; you saw good results with the second and third; by the fourth you knew you had something! Now you want to roll it out across the entire organization. But each of your teams approaches agile differently. You’d like a consistent approach, but you don’t want to stifle the culture of cooperation and coordination that agile has brought to the organization. How do you scale with a consistent approach that also supports The Manifesto?

Metrics can backfire. They are useful for both self assessment and retrospectives. But experience since 2002 with 80 teams at IBM has shown it’s not just a matter of finding the right metrics. It’s important to use them properly, and avoid common pitfalls, including bloated metrics, the evil scorecard, lessons forgotten, forcing process, and inconsistent sharing. Turning assessments into “un-assessments” returns power back to the team. Instead of defining more metrics, this paper tells how not to misuse them.