Writers Workshop C - Chopin/Creedence Clearwater Revival

Patterns and Advice for Managing Distributed Product Development Teams

These patterns are based on several years of experience within an oilfield services company running development teams that are geographically distributed. They need to deal with a substantial time difference and fundamental cultural diversity. Experience from managing these teams has been collected in a written form from various managers, and from memos with recommendations. The information collected was not in a form where it was easily accessible for new teams. Our aim is to generate a collection of standalone documentation to support distributed project teams on the journey to a successful product delivery.

Patterns for Leading Effective Meetings

Statistics reveal that out of professionals attending meetings on a regular basis - 91 % admit to daydreaming during meetings - 73 % say they have brought other work to meetings - 39 % say they have dozed during meetings Many of us spend a high percentage of our work time in meetings. Often these meetings are frustrating as they seem endless, ineffective and a waste of time. But meetings are essential to business life. They are necessary for planning, reaching decisions, building teams, finding solutions... As we all know and countless books on leading meetings state, meetings can actually be made effective, energetic and fun... This paper has collected four patterns on leading meetings effectively. They are obviously not a pattern language but maybe a tentative start of a pattern collection...

XP Expanded: Patterns for Distributed eXtreme Programming

The ever--increasing globalisation of businesses that consume development effort leads to the desire to create development organisations that span the world. At the same time, XP and other Agile approaches to development emphasise the importance of close communication and collaboration. While these two forces on development teams seem  to be in flat contradiction, in fact a body of techniques for successful distributed Agile development is beginning to emerge. These few patterns record those facets of one successful distributed XP team's practice that seem to be widely shared amongst distributed development efforts with an Agile bent.

Patterns for Extreme Programming Practice

This set of patterns is intended to complement the standard wisdom that can be gleaned from the Extreme Programming literature such as Kent Beck's Extreme Programming Explained. It is directed primarily at those who are starting out with Extreme Programming and might miss some subtle ideas. Once a team gains experience these patterns will become obvious, but initially some of them are counter intuitive.

Have it Your Way

Everyone involved in the software development process makes decisions. Having appropriate decision support is one part of the process, but sometimes the greater challenge comes after making the decision: actually having the decision adopted and carried through. For Project Managers and Technical Leads, being able to get your decisions acted on gracefully and managing their outcome (good or bad) is one of the set of skills that belong in any manager or leads toolbox. This paper presents four patterns that capture the common practices necessary to have decisions adopted.

Technical Vendor Selection Patterns

The vendor selection process is a key part of a commercial off the shelf software based development project. Vendor selection involves a broad community including business representatives, technical teams, functional experts, contract negotiations

amethodology

You're sitting there, contemplating the start of a new project. You have (perhaps) a potential team of programmers, project managers, office cleaners, specification gurus, architects, testers, telephone sanitizers, configuration management specialists etc. How are you going to coordinate them? How are they going to coordinate themselves? Even imagining the strictly personnel management side has been taken care of (or not) according to the whims and working of your company; the technical management is more difficult. You'll need an agreed way of working, of agreeing in advance what we're going to do, of cementing technical contracts between developers - in other words, you need a methodology. There are many Audi-driving 'consultants' who will gather around to help you help them meet their sales quotas. But how do you make the right decision?