Skip to content

Teaming

By Woody Zuill

A Book Recommendation: Teaming, by Amy C. Edmondson

Amy Edmondson has done a great deal of research and writing on the topic of Teams and Teamwork and how it fits in to the modern world of work.  Her book, “Teaming, How Organizations Learn, Innovate, and Compete in the Knowledge Economy” brings together a lot of great thinking and ideas.

Edmondson introduces the idea of Teaming as a verb and as a way to approach working with others:

Teaming, coined deliberately to capture the activity of working together, presents a new, more flexible way for organizations to carry out interdependent tasks. Unlike the traditional concept of a team, teaming is an active process, not a static entity.  Imagine a fluid network of interconnected individuals working in temporary teams on improvement, problem solving, and innovation. Teaming blends relating to people, listening to other points of view, coordinating actions, and making shared decisions.  Effective teaming requires everyone to remain vigilantly a aware of others’ needs, roles and perspectives.  This entails learning to relate to others better and learning to make decisions based on the integration of different perspectives.  Therefore, teaming calls for developing both affective (feeling) and cognitive (thinking) skills.

While in our Mob Programming approach the team is relatively stable compared to the model Edmundson is presenting, I believe many of the same skills that “Teaming” requires are also helpful on our team.  Much of what Mob Programming is about is that “teamwork” isn’t what you get from a team – it’s what you bring to the team.  I think this book takes the same point of view.  For example, she provides a list of behaviors that drive Teaming success that matches very nicely our basic “Mob Programming” and Agile philosophy:

Speaking Up: Teaming depends on honest, direct conversation between individuals, including asking questions, seeking feedback, and discussing errors.

Collaboration: Teaming requires a collaborative mindset and behaviors – both within and outside a given unit of teaming – to drive the process.

Experimentation: Teaming involves a tentative, iterative approach to action that recognizes the novelty and uncertainty inherent in every interaction between individuals.

Reflection: Teaming relies on the use of explicit observations, questions, and discussions of processes and outcomes.  This must happen on a consistent basis that reflects the rhythm of the work, whether that calls for daily, weekly or other project-specific timing.

These ideas mesh very nicely with my thinking and the things I’ve experienced and observed in Mob Programming.

The book also speaks a great deal about the leadership aspects of setting things up to gain the benefits of Teaming.  In many organizations the nature of teamwork, teams, and teaming is ignored or not understood.  This book provides a number of ideas about what leaders can do to better learn about, understand, and encourage Teaming in their organizations.  Each chapter has a Leadership summary and a list of Lessons and Actions that focus things rather nicely.

If you are a team member, team leader, manager, individual, or human being of any sort interested in having a better understanding of collaboration and teamwork in the modern workplace or organization, I highly recommend this book.

Mob Programming Workshops in Finland and Sweden this Fall

If you are interested in participating in a Mob Programming workshop, where you can experience our Teamwork attitude and many ideas related to Teaming and collaboration, I’m providing several workshops this fall – one in Finland and one in Sweden:

Helsinki, Finland – October 23rd

Mystes Presents
STATE OF THE ART PRACTICES
IN AGILE SOFTWARE DEVELOPMENT
Woody Zuill, Vasco Duarte & Llewellyn Falco
October 23rd & 24th, 2014

I’ll be doing a half day workshop on Mob Programming, along with 3 other workshops covering 2 days.

Malmo, Sweden – Oredev 2014 – November 4th

I am very pleased to be returning to Malmo and the FANTASTIC Oredev conference!

Experience a full day of Mob Programming and learn the mechanics of how to work together as a “Mob”, and explore the underlying concepts that make this form of development so effective for my team.

Throughout the day we will be tackling a sample project and working on it using a full “extreme programming” approach – User stories, prioritization, test-driven development, refactoring, and retrospectives.

Hyper Teams

By Jason Kerney

Humans are notoriously bad at multitasking. Development is a complex undertaking that requires true multi-threading of tasks which all have interdependencies. A developer needs to balance architecting a solution, writing code, managing cross-project dependencies, and maintaining previous projects. Circling around actual development are issues of ensuring that requirements are correct, updating documents, managing requirement cross-dependencies and deciding which technology represents the best way to deliver the desired solution to the customer. These are just a sample of the things that a developer is expected to do. What is worse is that all of this is happening at the same time.  It is time for a multicore  developer. I have witnessed “Mob Programming” provide a solution to the need of a developer to multitask.

There are tons of benefits to well-written code. However, people’s ability to perform any task changes from day to day, and even hour to hour. So the quality of code that someone writes is the average of their peaks and their valleys. With the mob, since there are multiple eyes on the code, the code is written at the highest capability at the time. Since you are now averaging the rates of the highest performer, your overall average is significantly higher. The code my team has produced is the cleanest, easiest to maintain and the DRY-est code I have ever seen.

A team remembers at a higher fidelity than individuals or even the sum of those individual’s memories. Psychology has a theory known as “Transactive Memory” (http://en.wikipedia.org/wiki/Transactive_memory) which describes this process. I have seen the mob remember discussions with product owners about features we implemented a week after initial discussions complete with minute details. This leads us to implement the correct solution the first time and makes our business analysts feel like valuable partners because we “get” their intentions quickly.

Transactive memory has led to other benefits as well. The team notices when logic repeats, even when the instances of the logic have months between the initial writing and the current process. This happens even with uninteresting bits of logic or trivial solutions. Again leading to a cleaner overall design.

Being able to examine software design at multiple levels is a must for a developer. Architecture cannot only be considered at the application level any more. There is the architecture of the class we are working on and design considerations regarding that implementation. Individual classes and projects of classes does not cover everything either. We have to consider the design of our whole product suite. Everything a developer creates has shared knowledge, routines, and libraries. Lastly, there is the data architecture with relationships in data and data storage. Developers have to constantly be monitoring all of this. They have to be thinking how a change in one area will cascade through all others.

The mob has an interesting approach to this. There are multiple people participating in the creation of the code base at the same time. Since there are multiple people, each can, and often does instinctively, focus on different aspects of the architecture. With every decision, multiple people consider how that decision affects different parts of the whole system. Then, guided by each, we dive down and work through the changes at all levels. Everyone, though focusing on different parts, keeps the current context in mind and never loses sight of why these changes are made.

So, like I said, it is time for a multicore  developer. Everything I mentioned is constantly happening. The demands on developers today is that they have to not only approach all of this, but they have to be able to do it all at once. Most good developers try to combine tasks using clever tricks or rotes, smashing concerns until they can fit them into bite-sized chunks that somewhat relate. This falls apart as soon as something becomes different or complex.

For us, we found a different solution. The mob allows us to function as a single developer but with multiple cores. We are able to do everything I talk about above and more. We also have the benefit that all this is happening at the same time without distracting us from our current goal on hand.

I would like to state that “Mob Programming” should not be thought of as the only answer to the multicore programmer problem. I would even say it is probably not for everyone or every company. There are a lot of factors that allow it to work with my group. However, I do believe the problem of the multicore programmer is a real one. I also believe this problem is becoming more prevalent as time continues. I cannot wait to read or hear about how other people solve this problem.

Thank you,

R. Jason Kerney

Fading Problems

By Woody Zuill

{NOTE: This is a draft of a work in progress.  It is likely to change over time as I flesh out the examples given here.  It is likely there are spelling, grammar, and other errors throughout.  Please read past the mistakes.  I’ll try to get things cleaned up over time.]

Fading Problems

I’d like to introduce a concept I am calling “Fading Problems”.  After doing Mob Programming for a while we started noticing that many of the problems we previously faced were no longer affecting us.  While we didn’t directly attempt to solve these problems we noticed some problems were simply fading away.

Mob Programming encourages a very Agile way of dealing with things.  The practices and techniques we follow support the concepts outlined in the Agile Manifesto values and principles (AMVP), and we use the AMVP to evaluate the practices and techniques we are using or want to try. Even more meaningful to us is that this almost automatically happened by simply “turning up the good” of collaborating and working as a whole team. For example, face to face (and side-by-side) communication just naturally happens when we all sit together throughout the day.  Another example is by having 5 or 6 sets of eyes on our code and scrutinizing our designs leads gives us continuous focus on Technical Excellence and Simplicity, and many other good things.

Here are some of the problem areas that seemed to  just fade away as we built our Mob Programming and collaboration skills.

  • Communication Problems
  • Decision Making Problems
  • Doing more than is barely sufficient
  • Technical Debt
  • Problems related to Scheduling, queuing, estimating, prioritizing
  • Thrashing of team members, and the team
  • Politics
  • Meetings

Communication Problems

There are many communication problems in software, so I’ll just cover a few here: Latency in getting answers to questions, Communication by Email, Communication by Documentation.

Problem: Getting Answers to Questions can take a lot of time.

It is not uncommon for a developer (or anyone) working on a project to come upon a question that they can’t answer themselves and therefore need to seek out the person with the answer.  If the question blocks the developer from making further progress until they have the answer they might need to switch off to some other work. Alternatively they can make a “best guess” at the answer and confirm the correctness of the guess later.  There are other ways to approach this, but regardless, none of them are better than getting the answer immediately.

We typically have many questions throughout the development of a project and if the amount of time we spend waiting for answers is more than 2 or 3 minutes it can become a serious problem.  Being able to get questions answered in 2 hours as opposed to getting an answer in 2 minutes can potentially slow down a project by nearly an order of magnitude.  In some cases it can take 2 days or more to get an answer.  This introduces a great amount of waiting time, and destroys our ability to deliver working software “early and often.”

For example, if you have 10 questions that arise, and it takes 2 hours to get each answer, that is 20 hours, or ½ of a work week.  If those same 10 questions have a 2 minute answer time, you have only 20 minutes of wasted time and you can get the feature done by lunchtime.  Imagine if it took two days to get each answer?

With Mob Programming a great deal of this problem merely faded away. For questions that can be answered by other team members, we have completely eliminated any latency simply because whole team works on the same thing, at the same time, and in the same space.  All questions that can be resolved by another team member are always addressed immediately.

However, we’ve taken a further step. We ask the “product owners” (our Partners) to collaborate closely with us throughout the development of their project.  We think of this as an informal agreement to collaborate, and it has two parts. The first part of this agreement is our partners will join us daily for an hour or so to work with us in our team area so we can demonstrate the work we have just completed and discuss the work that we will tackle during the next 24 hours.  That in itself is a big help, and we generally find there are very few unanswered question when we are working in daily “iterations”. The second part is partners agree to be available throughout the day to answer any question, either by instant messaging, phone, or screen share. We strive for a 2-minute rule where any question can be answered within 2-minutes, if at all possible.

Problem: Communication by Email 

Asking questions by Email is a last resort for us.  In “Communication by Email”, a simple question or request can take many emails back and forth as people clear up misunderstandings and move toward a shared understanding.  People become very careful when communicating by emails, as there is a chance that anything you write will be held against you at some later point.  We become more and more cautious the more important the topic of the conversation.  We start adding other people to the email chain, such as our boss or other people who need to be part of the discussion.

With Mob Programming our style of continuous communication and rapid conversion of ideas into deployed, working code allows us to eliminate most of the need for email.

Our preferred communication hierarchy is 1) Face-To-Face, Side-By-Side, 2) phone and screen share, 3) instant message, 4) email. We never move to the next level unless it’s the only option to keep things moving.

Problem: Communication by Documentation

We write very little documentation. “Communication by Documentation” is typically a “one-way street”.  This leads to problems because detailed documents tend to be open to misinterpretation, and the more detailed the worse it gets. Documents are often written long before there is any way to validate their correctness, and often the person who wrote the document is no longer available to help when questions arise.

We eliminate most Communication by Documentation by continuous communication.  It is rare that we need a document to describe functionality we will work on since we work in small pieces and always achieve one-piece flow.  We quickly validate our understanding by demonstrating and putting into use the code we just wrote.  We encourage our partners to create and use any documents they feel they need. However, when it comes time to communicate their intent to us, we do it verbally and on the white board in face-to-face interactions.  This then quickly gets translated into code, and verified or validated the next day or as soon as possible.  Again, the “one-piece-flow” nature of our work style makes this straightforward.

Decision Making Problems

I have noticed two problems in decision making that commonly occur in software development: Reluctance to make decisions, and the need to defend decisions once they are made.

People are often reluctant to make decisions for fear of blame and retribution for bad or less than ideal decisions”, and perhaps for other reasons.  We do a lot of work to make sure we make “good decisions”. We analyze, create documentation, hold meetings, get confirming opinions, have people “sign off” their approvals, and hedge our bets the best we can.  Once the decisions are made and work has started based on them, we often must defend them and find ways to protect ourselves when things aren’t working out as well as we hoped.  We become biased in favor of the decisions we have made, and rationalize them.

With the Mob Programming approach, nearly all decisions are made together by the entire team.  We recognize that there is no one to blame, and that we can easily reverse many of our decisions with no adverse consequences. We put less emphasis on making sure our decisions are “right” beforehand because we know will quickly have feedback and whatever we learn (good or bad) will allow us to steer.  Since much of what we do is done by a team, the qualities of our decisions are better than we would have had working alone.  We need no meetings, signoffs, or documentation because we are always open to changing direction and improving things.  Since our focus is on experimenting and getting rapid feedback, we no longer think of decisions as being “one way or the other”, but rather as an opportunity to learn something which will allow us to steer to a better solution as we gain understanding.  This extends to our product owners and customers as they can try things in small chunks and also steer to better results.

Doing more than what is Barely Sufficient

It’s useful to learn to discover “just enough”. Any work we do that doesn’t need to be done is waste. A project should have only the barely sufficient set of features to provide the desired functionality, and each feature we create should have a barely sufficient implementation.  Anything more than barely sufficient uses time and effort with no return, unnecessarily complicates the project, increases the chance for bugs and problems, and makes maintenance and enhancements more difficult.

We attempt to get something coded and delivered into actual use every day.  By having a daily deadline and working on only one thing at a time it is easy for us to stay focused on keeping things simple so we can quickly get something working and into use.  This naturally keeps everyone from adding things that are unneeded.

We consider our Partners (internal customers and product owners) to be part of the team, and they work closely with us to do only what is “barely sufficient” so they can get the functionality they seek as quickly as possible.  When we occasionally slip up, someone on the team will notice and get us back on track. “What can we do to get this idea into use today?” is our constant guiding light.

Technical Debt

Technical debt is a progressive, debilitating disease in code, and quickly destroys our ability to sustainably deliver value.  Conceptually, technical debt is anything in the code that makes it harder to work on than it could otherwise be, and when we allow it to exist it progressively becomes easier to accumulate more.  Technical debt can take many forms.  We’ll look at one example here, and how Mob Programming allows us to deal with it.

The “Oddball Solution” code smell:  Duplicate code is one type of technical debt. Unfortunately, duplicate code is not always obvious. One kind of duplicate code is called “Oddball Solution”.  One example of this is when we have two different solutions for the same or a very similar problem.  This often happens when several programmers have individually coded the solutions in isolation from each other.  There is a pattern to be found, but developers working individually on different but similar stories typically do not have an opportunity to notice patterns either in the problems they are working on, or in the solutions they devise.

While a code review might reveal these things, code reviews are done “after the fact”, and unless the code review for both solutions are done by the same person the pattern will likely remain hidden.  Additionally, dissimilar solutions to similar problems are often sufficiently dissimilar that they are not easily noticed even when the same reviewer is reviewing both solutions.

In working as a Mob all work is taken on in a sequential “one piece flow” manner. The whole team is aware of each problem, and each person helps devise every solution.  The chance of noticing that something we are working on today is similar to something we worked on recently is much more likely than when working in silos.  We have had many instances, even months later, where someone on the team recognized that something “seems familiar” about something we previously worked on, and the group memory of the team allows us to quickly locate the previous situation. We can then investigate solutions that will allow us to abstract out the commonality and create simpler solutions with less duplication.

With more eyes on all work, and more discussion about keeping things simple we notice problems like duplication, hidden patterns, and other code smells and technical debt pitfalls.  We have a collective interest in Clean Code and encourage each other to keep our code in great shape.  Less is “put off for later” as someone will generally notice we are doing something stupid to ourselves and point it out (with kindness, consideration, and respect, of course.)  Additionally, whenever someone senses something is harder to do than we might think it should be they’ll mention it and we’ll take time to see if there is some hidden technical debt slowing us down.

Problems related to Scheduling, queuing, estimating, prioritizing

Estimating, prioritizing, queuing, and scheduling work is a common part of managing software development in most organizations.  While this adds no value to the work being created, it is often thought that these things are necessary to manage the work.  If we could get our work done just as well without these things, we could eliminate the waste.

With Mob Programming, we take on work one piece at a time so the whole team can focus on the current work item.  The whole team, including business people and customers, discuss the work we are currently taking on and work together to identify the details. We identify some discrete and yet cohesive part to work on, and decouple it from the remaining work of the project. Little or no work is done on any “story” until we are ready to work on it. Once we’ve settled on the nature of the story, we code it, put it into production, and validate its usefulness.  Only then do we begin work on the next idea.  This approach allows us to eliminate most “up front” scheduling, queuing, estimating, and prioritizing.

Thrashing of the Team Members, and the Team

I am using the term “thrashing” here as a placeholder for a number of typical activities that detract from a person’s ability to effectively do their work.  As an example, a developer can be taken off of their assigned workload and asked to work on an emergency or urgent task.  There are at least three harmful conditions that are the often the result of this type of thrashing:

1) The developer must take their attention from the work they are doing, thereby losing the thinking and time they have invested towards understanding the problem and solution.  They might not be able to easily get back on track when they finish the emergency task.  In some cases they might not be able to get back to the original work for weeks or months, but even being distracted for just a day or two, or even an hour, is enough to cause problems.

2) If other team members are counting on the work the thrashed developer was supposed to be working on, their work can also be held up or blocked.

3) It is common that the “thrashed” developer is the “go-to” person on the team.  They are proven problem solvers, and that is why they are sought out to help with the emergency tasks.  If this developer is taken away from the rest of the team to attend meetings or to work in another department, the team loses their most valued member and can flounder without their trusted and capable guide.

That is just one example of thrashing.  Other typical examples will are unneeded meetings, casual distractions, busy work, disruptive noises, postponing of work already started, and task switching to accommodate phone calls and other intermittent requests.

There are at least two ways to deal with thrashing problems. One is to prevent it from happening, and the other is to make it irrelevant when it happens.  We apply both of these approaches with Mob Programming.

1) Prevent it: By working in a one-piece flow manner, we work through things quickly and there is much less chance of us starting on something and then getting interrupted. When emergency work is brought to us, we simply work on it as a team. No one is taken off the “current work” because we take each piece of work as a discrete task.

2) Make it irrelevant: In the case where someone is called away to work on an emergency, the work does not stop since there is a team level understanding of all the work we do.  When that person returns, they easily get back up to speed.  Also, the “team memory” helps in the rare occasion where we must set aside our current work in the middle of working on something as we can quickly remind each other of the our train of thought when we resume the interrupted work.

Politics

There are a number of issues related to politics in any business. Often there are cross purposes between teams, departments, roles, individuals, and so on. Even worse, there are well known issues like power plays, territorialism, parochialism, empire building, and many others.  While Mob Programming does not help much with all of these possible issues there are some “Developer Level Politics” that we feel are reduced by Mob Programming.

One example of “Developer Level Politics” is how willing people are to help each other.  In some organizations with the typical performance appraisals to determine bonuses, raises, and promotions and you will be judged on how well you get your work done.  In some situations you do not get credit for helping others and must focus on your own work.  There is little or no incentive for helping others. Helping someone else uses up the time available for working on your own work.  There work gets done quicker; your work is not getting done.

When we all work together, all day, every day, the work of the team is what is important to everyone. There is no “me vs. you”.  The basic idea of a “self-organizing” team is that each individual can decide where, when, and how they can best contribute.  We engage and contribute in any way we feel is helpful.  Helping others happens naturally because the end result of the team depends on us working well together.

Meetings

In the common pattern for meetings we gather, share information or are shown information, make some decisions, make some assignments, and everyone goes away – some to do work, others to manage work.  I see this as often resulting in a harmful separation of “work” and knowledge creation from decision making.

After the meeting the folks that need to ask questions are separated from those who can provide answers and information.  Those who can validate things are separated from those creating things to be validated.  In other words, while we might be working together for a short time, and we are aligned to some degree at the end of the meeting, it is a very fragile alignment. We start diverging quickly, or even immediately.

This “gather, share, decide, assign, disperse” meeting style is not a very collaborative way to work, and often leads to the need to manage the meetings and the work agreed on during the meeting.  We need extra tasks and artifacts like agendas, meeting minutes, follow-ups, email communications, check lists, spreadsheets, and so on to deal with this. After the meeting any questions, clarifications, validations, and so on require that we track down the right person to help us. Communication is put into queues, and done via emails, phone calls, and follow-on meetings.

With Mob Programming our entire day is a working meeting, and more like a workshop than a meeting. We are working together, not merely “meeting”. We share information, decide what to do, do it together, verify our understanding, adjust our understanding about the next reasonable thing to work on, work on it, and so on, over and over. We collaborate and remain in alignment all day long.  Any questions are answered immediately.   Work is validated as we go, and it is put into use as quickly as we can, often on the same day it is coded, which allows for users to verify its value.  We find very little need for planning meetings, stand-ups, review meetings, and most of the common meetings that plague the typical development organization.

Conclusion

I’ve covered a few of the problem types that are common in many organizations.  These are things that can be addressed by Agile and Lean thinking, and that I feel our “Mob Programming” approach has helped to lessen or eliminate many of these problems by simply “turning up the good” on a few key things:

  • Continuous collaboration and communication throughout the team, and with our work partners
  • The almost automatic application of a “limited WIP” and one-piece work flow
  • Frequent delivery of software into use and the rapid feedback this provides
  • Holding frequent and meaningful retrospectives.
  • Other things I’ll probably think of later.

So there you go.  This is just a “first draft”.  Perhaps I’ll get back and work on this now and then.

Cheers!

 

MobProgramming Workshop at Tagged in SF

What: Learn about Agile and Extreme Programming using a Mob Programming approach, With Woody Zuill.

When: Thursday, February 6th, 2014

Where: Tagged offices at 848 Battery Street, San Francisco, CA

This one day workshop will allow participants to experience a day of Mob Programming. We will share not only the mechanics of how to work together as a Mob, but also the underlying theory we have found make this form of development so effective. Throughout the day we will be tackling a sample project and solving it using a full “extreme programming” approach – User stories, prioritization, test-driven development, refactoring, and retrospectives.

 At the end of the day you will come away from this class having experienced the joy and effectiveness of Mob Programming, as well as being equipped to continue on your own path.

Part of this experience is gathering what the individual participants most want to learn and adapting the experience to enable those outcomes.

We will probably use either C# or Java as the programming language for this session. However, the language is not important as long as at least several of the attendees are competent in the language we choose. It is not required that you join in the programming if you prefer to simply observe.

We will provide lunch, as well as drinks and snacks.

Note: Limit to 8 people per class.

Learnings:

  • How can 5+ people be effective working on 1 thing?
  • Guidelines for successful collaboration
  • Mechanics of Mobbing
  • Retrospectives
  • Tools for mobbing
  • Workspace setup
  • The theory of why mobbing is effective.
  • We’ll use a Test Driven Development (TDD) approach
  • Working with Product Owners
  • Refactoring

Meet your Facilitator:

Woody Zuill

Woody Zuill

 Woody Zuill is part of the team where Mob Programming originated. The timelapse video ( http://bit.ly/MobProgrammingVideo ) of him and his team started the entire “craze”.

He maintains the mob programming website, and was interviewed on multiple podcasts including .Net Rocks ( http://mobprogramming.org/our-mob-programming-team-interviewed-on-net-rocks/ )

Register HERE:

MobProgramming at Oredev

By Woody Zuill

I was invited to present our MobProgramming approach at Oredev 2013 in Malmo, Sweden.  It was an exciting and wonderful experience for me (to say the least), and perhaps someday I’ll post about it.

Until then, here is a link to a video of the session I presented there about MobProgramming:

MobProgramming at Oredev

Please let me know what you think, if you would.

 

MobProgramming Agile Workshop

What: Learn about Agile and Extreme Programming using a Mob Programming approach, With Llewellyn Falco and Woody Zuill.

When: Saturday, Dec 7, 2013 or Thursday, Dec 12, 2013

Where: San Diego Area (We haven’t chosen the exact location yet…)

We are presenting a one day workshop that will allow participants to experience a typical day of Mob Programming. We will share not only the mechanics of how to work together as a Mob, but also the underlying theory we have found make this form of development so effective. Throughout the day we will be tackling a sample project and solving it using a full “extreme programming” approach – User stories, prioritization, test-driven development, refactoring, and retrospectives.

At the end of the day you will come away from this class having experienced the joy and effectiveness of Mob Programming, as well as being equipped to continue on your own path.

Note: Part of this experience is gathering what the individual participants most want to learn and adapting the experience to enable those outcomes.

Note: Limit to 8 people per class.

Learnings:

  • How can 5+ people be effective working on 1 thing?
  • Rules for successful collaboration
  • Mechanics of Mobbing
  • Retrospectives
  • Tools for mobbing
  • Workspace setup
  • The theory of why mobbing is effective.
  • Test Driven Development (TDD)
  • Working with Product Owners
  • Refactoring

Meet your Facilitators:

Woody Zuill

Woody Zuill

 Woody Zuill is the illegitimate father of mob programming. The timelapse video ( http://bit.ly/MobProgrammingVideo ) of him and his team started the entire “craze”. He maintains the mob programming website, and was interviewed on multiple podcasts including .Net Rocks ( http://mobprogramming.org/our-mob-programming-team-interviewed-on-net-rocks/ )

 Llewellyn Falco

Llewellyn Falco

 Llewellyn Falco is eXtreme programming expert. Track chair for Agile 2012/13. Creator of the open source testing tool ApprovalTests ( www.approvaltests.com ) and co-founder of the chairity TeachingKidsProgramming. He & Woody have been bringing their unique approach to learning and training to the community since 2008.

Register HERE:

Saturday, December 7, 2013 from 8:30 AM to 5:00 PM (PST) : https://www.eventbrite.com/event/8807213613

Thursday, December 12, 2013 from 8:30 AM to 5:00 PM (PST) : https://www.eventbrite.com/event/8807536579

Our Mob Programming Team Interviewed on .NET Rocks

We have finally hit the big time!!!

Our Mob Programming Team has been interviewed by Carl Franklin and Richard Campbell.

We had a lot of fun, and want to give a HUGE thank-you to Carl and Richard: THANK YOU!  It was a wonderful experience for us, and we really appreciate the chance to share our style of work with the .NET Rocks audience.

Here is a link to the interview:  http://www.dotnetrocks.com/default.aspx?showNum=912

And here is a link to a few interesting articles here:

Mob Programming Basics: http://mobprogramming.org/mob-programming-basics/

3 minute time-lapse video of a full day of us working as a Mob: http://mobprogramming.org/mob-programming-time-lapse-video-a-day-of-mob-programming/

Thanks for visiting!!!

Get a good start with mob programming

Author: Per Jansson

A Note From Woody: This is a guest article provided by Per Jansson.  It was posted on his blog and he has graciously allowed us to reproduce it here.

Here is a link to his blog: http://pichdude.wordpress.com/2013/09/15/get-a-good-start-with-mob-programming/

Thanks Per!!!


This is the story about how we in our development team used mob programming as a way to develop software.

Introduction to mob programming

I’m going to start by quoting Marcus Hammarberg, an excellent colleague of mine at Aptitud, since he describes the core of mob programming in a good way:

”The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course). It’s just like doing full-team pair programming.”

Continue reading ‘Get a good start with mob programming’ »

Mob Programming – Your Way

Nimble Thoughts by Dexter Baga

What is Mob Programming?

“Mob Programming” is simply a name we coined to describe/define what we do in our daily development tasks that allows us to be agile. We are a “Mob” since the entire team are always together, in the same room, walking together to meet a customer, making decisions together – essentially doing things together every time.

What it’s Not.

A large part of Mob Programming is about a mindset of making it easier to innovate and as a result we come up with good solutions. Mob Programming is not a set of processes that anybody can just adapt and expect the same “great” results. Continue reading ‘Mob Programming – Your Way’ »

Mob Programming: What about Ego?

What about Ego?

Today during the Mob Programming session at Agile 2013(#Agile2013) we were asked the question

“Does the Mob have to deal with issues related to Ego?”

Agile 2013 Mob Programming Talk

The Egotistic Developer

In my experiences in previous jobs, egotism came into play when a developer or manager attempted to push a personal agenda related to a decision suggested to the rest of the team and is unwilling to back down from that decision when it is questioned by that team. Continue reading ‘Mob Programming: What about Ego?’ »