Blogging and tweeting and Facebook... oy vay!

As an Agile Coach I need to maintain a social media presence so that I can keep up to date on my chosen field, learn from, share and maintain contact with my colleagues, be aware of relevant events, and show up on the radar of potential colleagues/clients.

While trying to keep up with social media personally is usually fun--though can easily turn into a huge time sink--trying to maintain a professional presence while tracking other professionals I admire and/or want to learn from can be daunting.

I want to keep up with the latest in my field and see what others are doing and experiencing and sharing but the beast requires that you feed it as well and that takes a LOT of time. One of the reasons I stopped blogging after nearly a year in the Philippines was because there just wasn't enough time.

Now granted, I was also trying to maintain family and friend relationships with people in the US while creating and nurturing new acquaintances in Manila, learning a new skill (scuba diving) which took me all over the Philippines, and actually work 40 hours per week (not to mention factoring in the traffic and increased travel time for even short distances).

But now that I'm back in the US and things are a little more 'normal' schedule wise, I still find it a large investment of time to maintain social accounts. There's:

• Facebook with family and friends; keeping up with what they're all doing and sharing our lives, photos, personal highs/lows, and political woes. As well as following my agency and other business pages (including my own which is in indefinite hiatus), etc.

• Twitter; a little more personally removed but no less relevant to my life and those aforementioned political woes. I have two Twitter accounts because I thought it would be smart not to share personal feelings/beliefs with my professional world, since for me it equals possible working relationships and clients. But it's more than twice the work; there's the emotional weight of not remembering which account I'm logged into and then deleting tweets sent from the wrong account and resending from the right one. (And I know by doing that I'm not being my whole self with those potential clients and working relationships, but that's a whole other can o' worms. A girl's gotta eat and pay her bills and keep her stress levels down.)

• Instagram; a place where I can follow people I admire or am interested in and share my own updates with family, friends, and complete strangers--which sounds weird, but I find it oddly comforting. That we can all connect over photographs of nature or other shared interests but maintain that distance... like a gallery or museum. Plus, as an amateur photographer it's validating to have people like and comment on my photos.

• LinkedIn; where I want to be more active--I currently check the feed about once a week, 'like' posts and sometimes comment--but feel reticent about say, publishing articles since it's more professional in nature and topics, and my first instinct is I don't have anything new to add, or better or more enlightening to say than others. (Yes, I have impostor syndrome; I'm working on that.)

• Slack; where I am most active--mainly reading what others have posted; though that's great for me. Learning and understanding how other people are viewing the same things I see in our chosen field of work as well as those who are struggling and how they solved for those issues. I do try to participate and share--it's one of my goals toward dispensing with that impostor thought process. But I have six active Slack work spaces; one that I own and maintain.

• My personal blog; which I started thinking it would be about the transformation I was working on in Manila but more often than not blurred into personal posts. I realized that the whole culture shift was just as important as what I was doing as a coach during working hours; because I was working with people in that culture and needed to understand that if I was to understand them. (And now that I'm trying to get back to consistently posting to the blog, I think I should just go with the flow and not try to force it into a mold.)

I generally only use Twitter, LinkedIn and Slack for business, but all of it takes time; not just to read through the feeds and linked articles but to follow up, respond, or post requires thought and sometimes research.

And since it's the nature of the game I try to maintain a steady stream of timely and relevant content--depending on the account--which means looking ahead and scheduling (Hootsuite is great for this), as well as keeping my eyes and ears open for the new and yet unknown, which takes yet more time. It can be a huge mental lift, but can also be mentally exhausting too.

Sometimes I think back to the day when we didn't have this access to each other and to the world at large and wonder if it makes a difference to be so connected and to spend the time. If I stopped doing all of it what would happen? Would it really affect my day to day life and work opportunities?

But then I think about how I feel to see a post from someone across the world who feels the way I do about something and feel connected. A stranger likes a photo I posted on Instagram and maybe comments simply, "That's stunning" and I feel pretty good about that. I see updates from family and friends who live far from me and feel a little closer.

And I know that people have followed me professionally on Twitter because I offer something that most do not. My tweets are usually centered around lifting others up. I didn't set out to do that and didn't even realize I was doing it until I saw the responses I got from those tweets; likes, retweets and follows. I thought my brand was "agile coach" but I think now it's 140 character comments about how awesome others are; especially when said peeps are live. (Though I have no clue what that might be called, in terms of a brand.)

I think its important to stay connected; I think it makes the whole world a better place and feel a little smaller. I think sharing our hopes, photos, wonder, and the feelings those evoke are all good and truthfully Agile. I have said before, and will continue to say, I think Agile is all about humanity.

So for now, I'll carve out an hour or two a day (that's my new target) to read and respond, find new and interesting to share, post my photos, like my family's silliness, write about my professional challenges or thoughts and just generally participate in the sprawling, sometimes chaotic, hubbub.

Telling stories and playing games

As an Agile Coach I need to find a way to help people practice the concepts I'm teaching in a way that makes it relevant and easy to understand and apply so they can start using those concepts immediately in their daily work.

I've trained hundreds of people, spending thousands of hours doing it in three countries over the last 6 years. I learned pretty quickly that training had to be: 1) interactive--because otherwise I lost people after the first 20 minutes of a 4 hour class and really couldn't get them back, 2) culturally relevant--otherwise it made no sense to them; Agile is an easy concept to understand but not to apply, and 3) fun--because that's how you keep them awake and engaged for the other 3 hours and 40 minutes.

I started out using the penny game--and still use it because it's amazing how it makes a connection for people almost immediately and is fun--and some other well known and useful Agile games. (Shout out to Tasty Cupcakes, the best ongoing Agile game repository!). But the aftermath of my classes was that people really couldn't make the connection to working together with their Product Owner on writing stories--let alone write good stories.

I thought about this quite a bit early on and did tons of research and experimentation but many times I was trying something that I didn't fully understand myself or wasn't relevant to my life so my heart wasn't engaged. And I knew this was the case for my students too; I could see it in their faces.

But necessity and all that research and experimentation led me to creating a few great games/tools I use now whenever I have clients who need some practice. Here's one example:

Story Telling

This is a tweak on a game I found somewhere (I honestly can't remember where so if you know please comment and I'll add the attribute) to help illustrate why it's better to have whole knowledge of what you're trying to build and to work together to do it. It's best with at least 5-10 people participating; more people can make it take longer but is no less fun. 

The group selects the story elements together; depending on your group this could be time-consuming if they're all reticent to speak so I call out whatever culturally relevant ideas I can to get things going (Jon Snow or Elsa anyone?)

INSTRUCTIONS

Create a story by speaking only one word at a time. The story must include the following elements:

Story Elements:

• a character (can be a name)
• a household object
• a location

Rules:

• The story must “flow"
• Players can add the words “full stop” to indicate a new sentence (that's their word)
• The story elements the team chose must be used

I usually ask someone in the room to be the recorder so we can read it back at the end; I stress they should only capture each word spoken, not fill in the blanks or edit.

I don't give the group time to confer or allow them to talk while in the game, other than to say their one word each. They invariably try to help one another and I gently dissuade them.

Generally, it takes a few minutes for everyone to warm up and commit to being vulnerable and participate. And the resulting story is nonsense and might include some of the story elements the group chose but many times not all or they're stuck in there as an afterthought to be sure they meet the rules. 

After we laugh about the silly story, I ask the group, would you have created a better story if I told you what I was looking for--for example, a bedtime story, a scary story, a romantic story? 

Inevitably, they say yes, because they had no idea what story they were trying to tell and only piggybacking on whatever they remembered moments before they had to add a word. And not everyone knew the character or was familiar with the location chosen so had little idea how to contribute.

I have had a couple groups, already long time team members, do a passable job of constructing something that made sense but even their stories had no plot and held no interest.

Then, I ask them, if you knew what type of story I wanted AND I gave you time to chat about it would you have created a better story? Again, the answer is yes and a bit louder this time.

Some have told me they're great storytellers and if they have time to think about it they can weave a story that holds rapt little children and adults alike. Others have told me they need a chance to collaborate and talk it through before they tell it; they just can't come up with the idea on their own.

Pride starts to win out over reticence and they want me to know they can do better.

I don't have to tell you what I say next, right? (If I do, contact me and we'll chat.)

I could talk their ears off about how important it is to have the discussion with their team, Product Owner, leaders, etc about what they're creating/building and why, but this simple game--which takes 10-20 minutes depending on the number of people--illustrates it so beautifully and simply I don't have to go that route. They get it and it resonates.

I include other games in my sessions but this is usually the first one we play; I generally use it as an ice breaker as well as a segue into why everyone should care about the stories they're working on and who wrote them and what they actually say. At the first break of the day, the feedback is usually something about how fun it was and how it made them think. 

And that is really all I could ask for from people who give me some of their time. Please think about what we're doing and talking about so you an apply it in your life.

Check out the next post for some other games I use including one I created myself.

Holistic Agile

ho·lis·tic hōˈlistik/ adjective

characterized by comprehension of the parts of something as intimately interconnected and explicable only by reference to the whole.

What do you think scaling means?

Is it okay that only IT and software delivery teams are Agile?

Does it matter if HR and Finance, Sales and Marketing and other business units still do things the way they always have?

The truth is, without change throughout the whole organization it cannot truly be Agile. (Unless it started out that way; kudos to you if your organization did.)

But there is an assumption in many cases that Agile is only for software development teams or IT.

We have to open our minds to the possibilities of Agile and understand it's not a prescriptive set of steps but a different way of looking at things; a different way of doing what we do.

When we talk about scaling many of us think of starting with a pilot team and then scaling to the rest of the teams within the group--that's product delivery scaling--or we think of scaling to other groups within the organization--platform scaling, or we might think of scaling to leadership and helping them become more Agile in their thinking and interactions--vertical scaling.

There are frameworks out there to assist with those types of scaling--LeSS, DaD, SAFe, Nexus, etc. But they're all focused on software development to a certain extent. There is another form of scaling we're starting to hear more about.

Horizontal scaling or scaling outside software. I've heard it called holistic Agile and I like that because it deals with the whole not parts.

Most companies think that Agile is all about the development and delivery of their product and that it doesn't apply to anyone outside the teams delivering that product and maybe internal groups like IT. The truth is Agile is a complete cultural and mind set that must be implemented in all areas for true success and benefits. The great news for everyone is it works. Companies whose names you will recognize have done it and are reaping those benefits.

One example is Gap Inc. They adopted Agile in their HR department because, among other things, they wanted to cut down the time it took from resumes received in house to a candidate being hired. And many times not the best candidate; they were losing the best candidates to other companies, because it took them at minimum anywhere from 10-54 days and with maximum delays anywhere from 31-123 days!

That's a huge problem, especially if you need that person for critical development on a product that must meet a market timeline. It could mean the difference between success and failure for that product and maybe the company. And they're not the only company with this challenge.

The Gap HR team goal was to completely revamp their process and cut down the time it took to screen, interview, and hire a candidate by about 2/3 of the shortest time it took them currently. The amount they accomplished in three months might make your head spin. But that's what happens when you look at what you're doing in a new way.

Because many organizations think about Agile as a prescriptive methodology, they believe they just follow the steps and voila! they will be Agile. 

Just as looking through polarized lenses give you a different perception of color, and certain drawings change when looked at from different angles or by squinting your eyes, Agile helps you view things in a novel way.

Once you look at something through the Agile lens, you'll start seeing things you missed before. Think about those magic eye pictures with the hidden 3D picture. If you slightly unfocus your eyes the hidden picture jumps out at you. What you see completely changes. But the truth is, the thing itself--the picture--hasn't changed; only what we see or how we see it.

There's a reason MBAs predictably fail at the marshmallow challenge while kindergartners best them every time. The years of training to see things a certain way has rendered them unable to do anything else… to see it any other way. Participants in the exercise are given 20 sticks of spaghetti, one yard of rope, one yard of tape, and one marshmallow; then they're asked to build the tallest free-standing structure they can using these items in ~18 minutes. Oh, and the marshmallow must be on top.

The MBAs spend about 30% of the time they're given planning the perfect structure and allocating roles. They end up with a structure about 10 inches tall; the average structure is about 20 inches tall with kindergartners achieving that along with architects and engineers.

How can this be?

Innovation can't be taught. If you're taught that everything can be planned, and must be planned in advance of beginning, you are killing innovation. If innovation is dead then you can't see things in a new way, a new light, or with new eyes. Creativity and innovation are critical for companies to achieve the ability to pivot and change.

Those MBAs aren't stupid people and they might be creative in other areas of their life, but they have been inculcated with the belief that in work the plan is the thing--the plan is right and the plan will get them through. So much so that they spend about 60% of their time implementing the plan they created to build their structure and only at the end do they place the marshmallow at the top… only to watch the whole thing bend or crumble under the weight. They leave themselves little or no time, or thought space, to pivot and try something else. They worked on their plan in a vacuum.

The kindergartners on the other hand build something small and stable with the marshmallow on top in just a few minutes. They play and experiment with the rest of their time. They don't believe there is one right way to accomplish the goal. In the same time it takes the MBAs to build one structure the kindergartners build 4-5 different attempts. They don't know going in what it will look like or what will work but they end up figuring it out.

So what does all this have to do with scaling Agile outside software? Well, executing on a flawed plan is a guarantee of failure. Flawed plans occur when we don't take into account--or even know--all the variables, or more importantly, allow ourselves to experiment.

Innovation is part of the answer. We must believe that innovation is more important than the plan. Because IT IS. Sure, you need a starting point and a shared understanding of where you're headed but innovation isn't about being a fortune teller or seeing the future. It's about figuring it out as you go.

In nearly ten years of experience in Agile environments, I have seen many companies saying they want to "be Agile." They hire coaches and spend money on training to get everyone in software development to be and do and think and act Agile. Many times when they look back a year or two later they are confused about why they aren't experiencing the huge leaps in ROI they expected or seeing droves of customers adopting their offering. Some of them say 'well Agile doesn't work.' Rarely do they say, 'we need to figure out why this didn't work for us.'

When I talk with executives and ask them whether they think they night need to change their approach and look at how they do things in the rest of the company, they tell me 'oh things are working just fine in [insert department here].' The problem is they think they're working just fine because they aren't looking for what isn't working.

One of the things I tell people when I begin coaching them is once you start doing this thing called Agile you will see the things that don't work. They will be illuminated very quickly and clearly. The choice is to acknowledge them and address them… or leave them as is.

So what do you need to scale to the rest of the company? There is no special adjustment or implementation. Make the decision and then do the same thing with those other departments/areas as we do with software development and IT. It's not exactly the same but it's not that different.

We know what one what The Gap did with hiring in HR; the next step would be to start changing how we approach compensation and increases. How do we incent teams rather than individuals? Annual individual reviews create friction because it pits people against one another and that is anathema to Agile teams.

How about Finance? How do we fund teams or products rather than projects? Doing this removes a lot of up front guessing, negotiating, and jostling for supremacy in the money wars, as well as the creative financing on the back end when there is money left in other projects but not the one that we really need to finish and release. If we decide as a company what our highest priority is and everyone knows that and then fund that priority we don't have the problems the current status quo creates.

How about security and networks? Yes, it's absolutely critical to our company health to meet all the regulatory and compliance laws and rules, but we don't have to accept the bottleneck created when the security/network group is inundated and unable to review pending releases. How about we build those reviews into the overall roadmap/timeline and process rather than think of them as an afterthought? Remember when testing used to be the afterthought? Or how about we ensure that we build in the compliance and regulatory items in by adding someone from that group to the team?

The most important thing to do is to focus on building that cohesive, collaborative team feeling with everyone across the organization. Provide safety so everyone feels comfortable sharing their ideas--from the cleaning crew to the c-suite; provide clarity of vision and purpose so everyone knows what is most important to the company and understands their part in making it happen. This will foster a culture where dependability is de rigueur; no one wants to be the bottleneck or considered unreliable.

None of this is rocket science and you may have heard other people talking about these concepts. It's also important to know that you can't wait for someone else. You must step up and advocate for the change.

So if you're an team member, you need to ask the question, "Are we going to implement Agile to other departments outside IT/software development?" Back it up with some data; "There is a 6-week delay while we wait for approval from finance or network/security. If we were all collaborating from the get go we might be able to cut that in half or completely remove it." And you need to push back when you're handed an unrealistic deadline or given 5 number one priority items to work on; use real data as back up because that's what gets leader's attention and response.

If you’re a manager, you need to listen to your teams, look at your group and ask yourself what changes will make a beneficial impact, pull your colleagues together to talk about how you can get started; hold a stand up with them to keep track of how things are going and discover when and where you may need to tweak. Find a mechanism for sharing the impediments you encounter with your leadership so you can get help from them. Talk with your leaders about how you can get faster decisions; maybe outline a new paradigm where some decisions are made without executive input--share those decisions and results in full transparency so we can continue to build the relationships and trust we need to make it work.

If you're an executive, you need to start listening more and working with your people to figure out what should go into the vision and goals and how to make them crystal clear so everyone knows what they are. If deploying the product is the most important thing, then HR must fill the open headcount and Finance must approve the funding and not be bottlenecks. Sometimes that means cutting down the number of initiatives on the roadmap; maybe focusing on 1-2 instead of 5-10. You need to allow room for failure and encourage innovation and make time for both. You also need to learn how Agile really works; you can't cook without a recipe unless you have some experience as a chef.

If you're in Product Management you better be working with the customer every day to be sure what you're giving them is what they need and that the 1-2 items the organization is focusing on are the right things. And when that changes make sure everyone knows so we stop spending time and money on the wrong things.

Agile can be applied everywhere. It can and does work outside software development and IT.

It doesn't happen overnight; however, it does create short term wins while you strive for the long term change.

And this kind of environment creates joy, as Rich Sheridan talks about. Who doesn't want to work in a place filled with joy?

You should get started today looking at things in a new way and helping your organization do that too.

Newsletters, blog posts, and wiki articles = augmented coaching

Well, that was a long unplanned hiatus. Since last blogging I spent another year in the Philippines working and playing--learned to scuba dive and spent almost all my spare time doing that and traveling around Asia--and returned to the states permanently in late 2016. I'm back at work coaching in the US and trying to be active at blogging again. To wit:

As an Agile Coach I need to find a way to augment face to face coaching and/or leave behind words of wisdom that people can refer to so the work we've done to understand and apply Agile concepts and practices does not evaporate.

When I was in Manila, one of the realities was distributed teams. We were spread around the world in Phoenix, New York, India and Manila and though we tried to meet in real time as much as possible it was truly difficult. (See the 15 hour time difference)

This meant that when we held a workshop or class some team members would miss out because they were sleeping or otherwise engaged in their personal life; and even when everyone was available and learned together some of the details might elude them later.

Similarly, once I've left an engagement I've found that people ask me questions about specific things because they don't remember or weren't ready to take in the information as it was provided at the time.

It occurred to me that providing additional information might bridge this gap, but when I shared links to articles or book lists... well, cue the crickets. For some reason, the follow through wasn't there. People would not click the link and read the article or blog post, let alone find a book to read.

So I experimented. I started producing an old fashioned monthly newsletter complete with the banner headline, date, edition number, and preview of next month's articles. The content was based on whatever we were learning at the time as well as the things that we were experiencing.

Then I branched out to wiki pages for specific practices and concepts that the people I was working with were finding challenging.

I wrote some of the content myself but also reprinted or excerpted material from the very links I'd sent previously. I was overt about it too; including attributes and links to the original right on the page.

I created blog posts doing the same thing.

And people started reading them.

I know because they commented and/or contacted me to say "thank you", "that was thought provoking", or "that was information I needed."

I still don't understand the why. I'm pretty sure I covered in person much of what I was including in these missives, but maybe it's the delivery, or the openness, or the left-brain/right-brain thing.

But if they're getting the information they need in a manner that allows them to assimilate and then apply it, who am I to question? If they'll read it in an in-house publication as opposed to following a link to the original, is that bad?

Most of the coaching engagements I've worked on have included hundreds of people and many teams. One or two coaches can only do so much and be available so many hours in a day; if augmenting our presence and reinforcing the message is possible you better believe I'm going to do it.

Suffice it to say, I have expanded my coaching toolkit to include a scheduled sweep of my favorite blogs, online sites, and books for those nuggets to share with my clients.

Catching up

Wow. So much has been going on and I've been so many places it's hard to keep up with myself. Here is a quick recap.

In late August I traveled to the states to see my family and work with some of my colleagues in the Phoenix office for a couple weeks. I planned to take time off while there but ended up extending the trip by a week and working almost the entire time. This turned out to be a good thing for work but not for me or my family.

I returned to Manila mid-September and, while trying to fit in some day tours of the Philippines, starting planning a trip to India to meet and assess the teams there to see what they might need to help them in the transformation. One team is in Kochi, on the southwestern coast of India and the other in Bangalore.

My colleague and I planned a couple days to sightsee while we were there, but it really wasn't enough.

India has a beauty in the culture and architecture that requires time to savor. Luckily, it looks like we'll be headed back there early next year.

In the meantime, I started to take scuba diving lessons with an eye toward certification.

I have seen and climbed Mt Tabaro, which is located in Taal Lake--it's actually an island in the largest lake in the world on an island, and has it's own island--snorkeled and dived in Anilao, Batangas; and walked on the shores of the Arabian Sea and in a 1000 year old temple.

We were blessed by the monks in a temple in India and learned about the gods who watch over the people of India and will watch over us too. They're not picky; they offer protection to all.

I'll try to get back on track with blogging, but don't be surprised if my activities keep me so busy I can offer little but photo uploads!

Randomness

There is so much to see and do, depending where you go, in the Philippines that it's hard to share it all, but here are some random flora and fauna, market sites, and more.

Introducing Mob programming: The best team technique you've (probably) never heard of

Editors Note: I am unable to blog as I am traveling and my schedule has blown up, but I do have stuff to share; here is an article I read that I thought was pretty interesting. I like the concept and the name. This is reprinted in full from Infoworld.

Introducing Mob programming: The best team technique you've (probably) never heard of

 Mob Programming extends Pair approach for productivity, quality gains in software development

By Daniel P. Dern

For software design and development (and many, many other tasks), productivity is always a high priority -- and in pursuit of this is a seemingly never-ending supply of new methods, from Kaizen "continuous improvement" to newer ones like Agile and Lean.

One of the newest approaches is Mob Programming, an outgrowth of Pair programming, an Agile technique where two programmers work together, sharing a single computer and taking turns at the keyboard.

"We discovered the Mob Programming approach from what we had been doing as a learning technique," recalls Woody Zuill, Senior Consultant with Agile development firm Industrial Logic, in a phone interview. "We were using a Coding Dojo style where everyone works together at a single computer to practice solving a programming problem. The style was based on Llewellyn Falco's 'strong pairing' Driver/Navigator model of the pair programming method."

Mob Programming, says Zuill, "is basically an expansion of that approach: working in a group, with one person at the keyboard to 'drive' -- enter and edit the code -- and everyone else working together as the 'navigator,' 'guiding' what goes into the keyboard. The passing around of the keyboard was based on the principle, 'If I have an idea, I have to hand the keyboard to somebody else, so I can explain it, draw it on the whiteboard, and discuss it before it is keyed into the computer.'"

Working as a team, it's a lot easier to see patterns and to act on them.-- Woody Zuill

And after a few hours of working as a Mob, says Zuill, "We realized that it was working so well we wanted to keep on doing it for the rest of the day. And at the end of the day, we decided to keep working this way the following day. That was four years ago." Zuill eventually wrote write this up in a blog post titled "Mob Programming: A Whole Team Approach."

The software project that Zuill and his co-workers did their first Mobbing on was "very complex, requiring input from all the developers." So, says Zuill, "We thought that meant this approach was best suited for solving complex problems quickly. But once we got good at Mobbing, we realized that it also was useful for smaller, simpler problems, because you can often find a way to abstract or automate tasks that are easy or repetitive, like cleaning up items in a database. Working as a team, it's a lot easier to see patterns and to act on them."

Bluefruit mobs up

In November 2014, Bluefruit Software, an embedded software development firm, which had already been using Pair programming, decided to give Mobbing a try, based on the advice of Nancy Van Schooenderwoert, President of Lean-Agile Partners, Inc., a technology training and consulting firm.

The place that Mobbing has helped the most is merging code when people have been working alone and in pairs.-- Matthew Dodkins

"We were adding more engineers, and Nancy, who we'd been working with for several years, suggested Mob Programming as one way to mature technical leads faster," recalls Bluefruit's owner & CEO Paul Massey. "While Mobbing's having the whole team around one keyboard sounded even less efficient than Pairing, we decided to give it a go."

And it worked.

"The place that Mobbing has helped the most is merging code when people have been working alone and in pairs," says Matthew Dodkins, a software architect at Bluefruit. "In a day spent using traditional collaboration, you would have to first spend time agreeing on tasks, common goals, deciding who's doing what... and then going away to do that, write code, and come back and merge it, resolve problems."

By bringing everyone into the same room, "we try to merge frequently, and try to do almost continuous integration," says Dodkins. "A lot of code gets merged all the time. For a big code project, we try to do it all the time. When developers are programming individually, we can be 'lost in code' for up to a week. None of our mob merges last more than a day, as opposed to working for a week and only then learning you're off -- meaning several peoples' code doesn't fit together."

"We find Mobbing good for solving complex problems, and dealing with merges of code by multiple people," says Dodkins. "You get the power of everyone's knowledge on the problem. It's also a positive learning and social experience -- all the team members can learn about the project, and can contribute to difficult problems that are blocking the project."

So far, Bluefruit has used Mob techniques "on a bit of everything," reports Massey. "We've used it on projects for our blue chip clients like Electric Bike and Home Information Systems, where we may have a dozen engineers organized into multiple teams, usually with a maximum of six to seven per team. And we have a team of six, with maybe only one or two engineers, on a number of smaller programs for start-up clients -- this team may only all get together one morning per week."

The productivity payoff

Mobbing may sound counterproductive in terms of the use of developers’ time, but consider that “most organizations have frequent meetings with six or more people,” Zuill points out. "Think of these as working meetings rather than information-sharing ones. Software development isn't about being at a keyboard -- that's just how we get the work into the computer. But the work is thinking, and translating ideas into code."

Mob Programming can feel slower, but the payoff is avoiding bugs, and getting the results that you want.-- Nancy Van Schooenderwoert

"If you measure by features or other classic development productivity metrics, Mobbing looks like it's achieving only 75 to 85 percent of individual or Pair output for, say, a team of six or seven working for a week," acknowledges Massey. "However, there's more to productivity than that. In the course of that programming, everyone has contributed their knowledge, so there's no need for training at the end -- nor need to merge. And merging is the most difficult task -- you have to understand the code you are merging. Individual work may have unpredictable problems, or need work to fit together."

"Mob Programming can feel slower, but the payoff is avoiding bugs, and getting the results that you want," says Lean-Agile's Van Schooenderwoert. And mobbing can be contagious (in a good way, of course). "If you deliver code to a customer, you may get them into mobbing as a way to review the code with them."

Mobbing is catching on

Mobbing is still in its early growth phase, but it's catching on quickly, says Industrial Logic’s Zuill: "A year ago I did a conference talk in Sweden about Mob Programming -- and this past week, I saw listings for two sessions in Sweden from teams talking about how they had gone about it. In 2013, I gave a talk on Mob Programming in Stockholm at Ericsson, and when I gave another talk there the next year, three other groups did presentations on how they were using Mob Programming. And I know of at least two or three dozen companies doing a substantial amount of Mob Programming."

And Mobbing isn't just for software development, notes Simon Clements-Hawes, an embedded systems tester at Bluefruit. "You can use Mobbing for training, education and other tasks. I've used it for educating, and for project and task completion."

Similarly, Zuill notes, "I've talked with people who aren't involved in programming, like project management groups, real estate managers, and finance companies who are using the Mob method. Mobbing is about working together on knowledge-based or thinking-intensive tasks." 

How to get started with Mobbing

"Getting started with mobbing is very simple," says Zuill. “I and others offer workshops on this, but Mobbing is an easy enough concept that you can experiment with it simply from watching online videos."

Mob Programming is one of the least complicated things to pick up. I suspect that in some of the places that aren't adopting it, it may be due to the culture. -- Paul Massey

"There are a few simple guidelines, but the core is 'learning to work well together,'" advises Zuill. "You need a few mechanisms to share information, which is why the driver/navigator model of any idea going through somebody else's hands is important -- the people trying to solve the problem have to explain it to somebody else. This enforces clarity of thinking, versus somebody trying to unravel intent from code. And we want the code to express that intent -- that's about the quality."

Mobbing has two important real-world requirements: a room with a large enough space, and a projector or other large display to allow everybody in the room to see the code on the "driver's" screen. (A blackboard or whiteboard wouldn't hurt, either.)

While Pairing and Mobbing are usually done live, "we have experimented with Pairing remotely, as long as you have good communications," notes Bluefruit’s Massey. And, adds Lean-Agile's Van Schooenderwoert, "remote Mobbing and Pairing is easier to do if the people have already worked together."

"Agile is all about feedback loops. Mobbing is an extension of it," says Bluefruit's Dodkins. "And getting people together in a room is more collaborative. You can look at each other and gesture and express things better than online."

"Knowing we wanted to do mobbing influenced the layout for our new office," says Massey. "We made sure we had a space for teams to spontaneously mob."

"It was helpful to be shown the ropes, but Mobbing is pretty straightforward," says Massey. "Mob Programming is one of the least complicated things to pick up. I suspect that in some of the places that aren't adopting it, it may be due to the culture. This is the most self-propelled practice I've seen. Within a few weeks after training, we were using it successfully."

No silver bullet

Mobbing can't be the only tool in your arsenal, of course, and it isn't a replacement for solo activity. "We don't do this exclusively -- maybe only about a tenth of our time is spent 'mobbing,'" says Bluefruit's Dodkins.

"As with any practice, too much of one thing can be bad," adds Bluefruit's Massey. "For us, the Agile process is a set of principles, and Mob Programming is another tool in the toolkit, along with Pair programming, Test-Driven Development, Behavioral-Driven Development, and a dozen or so others."

"One drawback of mobbing is that while you get the benefit of all people's brains in the room you still need someone to review the code -- which should be somebody who's not in the room," says Dodkins. "If you aren't reviewing your code, good luck -- all code needs to be reviewed."

"Also," stresses Zuill, "I like Mob programming and feel it's good for people to learn it -- but more importantly I feel teams should work hard to figure out what works well for themselves. To figure out their own process by frequently reflecting, tuning and adjusting."

And, says Zuill, there's an unexpected social benefit to Mobbing: "We have found at our workplaces that, by working this way, everybody on the way feels more fulfilled in their lives. We work as a team all day long, and we are uplifting each other and helping each other have a better life. We didn't expect that. And I see this at many places where Mob Programming is being done."

Resources

·        Read more about Mob Programming at MobProgramming.org.

·        Learn about Mob Programming workshops by Industrial Logic

·        Want to see Mobbing in action, watch the time-lapse video below of a day of Mob Programming.