Software Teaming (Mob Programming) is a cost-effective, collaborative and fun way to get work done together.
 
It's a whole-team approach to development, where coding, designing, testing, and working with the "customer" (partner, Product Owner, User, etc.) is all done as a team.
 
In this session we'll cover some of the important ideas that I used as guidelines in working with the team that resulted in the Software Teaming (Mob Programming) approach to the creation of software as a team which is now used all over the world.
 
The 4 main points I'll touch on are:
 
1 - Make it Easy for everyone to excel
2 - Turn Up The Good on the things that are going well
3 - The Failure to Communicate (and a little on how to deal with this)
4 - Leading from Within (and from without) - the need for each of us to lead and follow dynamically

The default use of an "estimate-driven" approach is pervasive in software development efforts, and while estimates can be useful, it is worthwhile to scrutinize our use of estimates for cost, time, and effort, and to seek better ways to manage software development projects. We say we depend on estimates to make important decisions, and yet we’re often disappointed by the results.
 
We'll explore the purpose and use of estimates in the management of software development efforts, and consider possible ways to work without trying to predict the future. There are a number of things to explore and many questions to ask. For example, are we getting a reasonable benefit from estimates? Is there a way to prove that estimates are helping us make good decisions? Do we really need estimates for all the things we are currently using them for? Is it possible to manage software development projects without these estimates, or at least with fewer estimates?
 
We’ll examine the nature of estimates in software development projects and look at a few ideas about moving beyond estimates.