Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders.

This is an evolutionary step beyond pair programming, and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development. Mob Programming can be a highly effective approach to software development.

Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we’ve faced.

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders.

This is an evolutionary step beyond pair programming, and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development. Mob Programming can be a highly effective approach to software development.

Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we’ve faced.

Mob Programming: All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer.

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.

Participants in this workshop experience a day of learning and doing Mob Programming. We cover the mechanics of how to work together as a Mob as well as the techniques that make this form of development so effective.

We'll learn how a Mob performs sample project work, including user stories, prioritization, test-driven development, refactoring, and retrospectives.

Designed and facilitated by Mob Programming pioneer Woody Zuill, this workshop provides a hands-on education in the art of mobbing and it's significant benefits for your teams.

The default use of an "estimate-driven" approach is pervasive in software development efforts. While estimates can be useful, it is worthwhile to scrutinize our use of estimates, and to seek better ways to manage the development of software when estimates are not appropriate. [NOTE: For this session, I am referring to the use of estimates of cost, time, or effort for software projects, features, or tasks.]

There are a number of things to explore. For example, do we really need estimates for everything we currently use them for? Are we getting a reasonable benefit from them? Is it possible to manage software development without them?

In this session we will start with an information gathering exercise to help us gain a shared idea of our current understanding of the purpose and use of estimates. From here we'll move on to examine the nature of software development projects and a few possible other ways to approach our work.

Five people at one computer? How can that possibly be productive?

While this seems like a reasonable question, it's not easily answered - until we begin to understand the power of flow.

Mob Programming grew from the quest of one team to learn how to work well together. Once we started We almost immediately noticed that working this way provided better results in a variety of ways:

• We were getting more done, and they were the more important thing
• The quality of our work was increasing dramatically
• Our Knowledge, skills, and capabilities were improving rapidly
• And all while we were having a lot of fun as well!

While we noticed these benefits and more, and it was clear this was in a large part due to working well together throughout the day - we didn't have an understanding of why this was working so wonderfully for us.

A hint came early on when we recognized we were achieving a one-piece flow - but we didn't realize the importance of this until we started exploring the meaning and power of "flow".

In this presentation, we'll share the results of that exploration, and see if we can get a better understanding of Mob Programming and the power of flow.

“The only sure thing about forecasts is that they are WRONG” – James P. Womack and Daniel T. Jones. Estimates have been the bane of software development projects for decision makers, managers, and programmers alike for decades. Managers/Customers want to know: When will it be done? How much will it cost? Which project should we do? Programmers are told: “A professional can do meaningful estimates”, and “We won’t hold you to the estimate”, and yet they often are.

It’s my contention that estimates are often not useful for this purpose, and even worse they can misinform the decisions they are meant to support. Do we really need estimates? Is simply “getting better” at estimates worthwhile? Can we live without them? Will things be better without them? I don’t have answers for you, but I’ve worked with “no estimates” for over 8 years and I’m still alive and doing well. We’ll explore the idea of estimates, what they are, why they are pervasive in the programming world, how they might be harmful, and see if we can start a dialog about finding a better way.

“The only sure thing about forecasts is that they are WRONG” – James P. Womack and Daniel T. Jones. Estimates have been the bane of software development projects for decision makers, managers, and programmers alike for decades. Managers/Customers want to know: When will it be done? How much will it cost? Which project should we do? Programmers are told: “A professional can do meaningful estimates”, and “We won’t hold you to the estimate”, and yet they often are.

It’s my contention that estimates are often not useful for this purpose, and even worse they can misinform the decisions they are meant to support. Do we really need estimates? Is simply “getting better” at estimates worthwhile? Can we live without them? Will things be better without them? I don’t have answers for you, but I’ve worked with “no estimates” for over 8 years and I’m still alive and doing well. We’ll explore the idea of estimates, what they are, why they are pervasive in the programming world, how they might be harmful, and see if we can start a dialog about finding a better way.

“The only sure thing about forecasts is that they are WRONG” – James P. Womack and Daniel T. Jones. Estimates have been the bane of software development projects for decision makers, managers, and programmers alike for decades. Managers/Customers want to know: When will it be done? How much will it cost? Which project should we do? Programmers are told: “A professional can do meaningful estimates”, and “We won’t hold you to the estimate”, and yet they often are.

It’s my contention that estimates are often not useful for this purpose, and even worse they can misinform the decisions they are meant to support. Do we really need estimates? Is simply “getting better” at estimates worthwhile? Can we live without them? Will things be better without them? I don’t have answers for you, but I’ve worked with “no estimates” for over 8 years and I’m still alive and doing well. We’ll explore the idea of estimates, what they are, why they are pervasive in the programming world, how they might be harmful, and see if we can start a dialog about finding a better way.

Let’s explore the purpose and use of estimates in the management of software development efforts, and consider possible alternatives. Why do we estimate and are we making estimates that are actually useful?  We say we depend on estimates to make important decisions, and yet we’re often disappointed by the results.

Why are we so challenged at estimation?  Are estimates for cost, time, or effort always needed? Is it possible there are other ways to approach our work?  If we didn’t estimate, how could we still be successful at making businesses successful?

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.

There are a number of things to explore and many questions to ask. For example, do we really need estimates for all the things we are currently using them? Are we getting a reasonable benefit from them? Is it possible to manage software development projects without these estimates, or at least with fewer estimates?  Is there a way to prove that estimates are helping us make good decisions?

In this session we’ll participate in some interactive information gathering exercises to see if we can gain a shared idea of our current understanding of the purpose and use of estimates.  We will examine the nature of software development projects and explore some real data to shed light on the art and science of software estimation.  Our exploration goal is to see if we can work together to come up with some ideas about improving on the traditional approaches to using estimates.

Let’s explore the purpose and use of estimates in the management of software development efforts, and consider possible alternatives. We depend on estimates to make important decisions, and yet we’re often disappointed by  the results. Are estimates for cost, time, or effort always needed? Is it possible there are other ways to approach our work?

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.

There are a number of things to explore and many questions to ask. For example, do we really need estimates for all the things we are currently using them? Are we getting a reasonable benefit from them? Is it possible to manage software development projects without these estimates, or at least with fewer estimates?  Is there a way to prove that estimates are helping us make good decisions?

In this session we’ll participate in some interactive information gathering exercises to see if we can gain a shared idea of our current understanding of the purpose and use of estimates.  We will examine the nature of software development projects, and see if we can work together to come up with some ideas about alternatives to using estimates.

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there has been a great deal of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.

The strength of Agile lies in the simplicity and clarity of the Values and Principles expressed in the Agile Manifesto. It can empower the people doing software development in any organization, and enable us to make rapid strides to the "land of better".

Software development is an activity of discovery. We must take action to reveal the reality of the problem at hand, the elements of the solution, and to reveal the work that is needed to design and create the software required. This is the process of discovery.

As leaders, activators, and influencers of change in the companies we work with, it's up to us to understand the philosophy of Agile and how it embraces and empowers the process of discovery.

I'll share my thinking about "Pure Agile", and how I use it in my daily work to enhance Continuous Discovery, Learning, and Growth in the teams and companies I work with. Let's explore together and discover the path to the future we want to create.

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there has been a great deal of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders.

This is an evolutionary step beyond pair programming, and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

Using techniques and ideas such as the "Driver/Navigators" collaboration practice, one-piece flow, sustainable work habits, continuous learning, and a philosophy of "getting along", Mob Programming can be a highly effective approach to software development. Whether done "all day, every day", or in a more limited way for special problems, kick-offs, and learning sessions, it can be a fun way to get work done.

Companies and teams all over the world are using this team-based approach to sofware development. Please join me for this introductory presentation as I share how the concept got started, some of the benefits, some techniques we use, and some of the problems we've faced.