Turning Mob Programming on its Head

I had a great conversation with Murray Robinson yesterday and he was citing articles like this https://www.wraltechwire.com/2020/01/28/pendo-study-with-80-of-features-not-used-software-execs-re-evaluating-success-metrics/ to talk about the percentage of features in typical software applications that are not actually used by the users when the application is put into production. So we're looking at around an 80% not used number, which reminds me ever so much of the percent of time that tasks spend in "wait" time before they move into "touch time", which hovers around 10%.

That wait time percentage is what lets various theories, like #TameFlow, that reduce wait time a huge impact. So, it made me wonder, what could we do to take a similar bite out of the 80% of unused features. My mind reached for recent thinking first :) and thought about Mob Programming...after working at it a little it came up with an old book about a MIT class called the "Fab Lab". The Fab Lab was a class at MIT where the students got access to a trailer truck full of computer-controlled fabrication machinery and circuit board printers. The response was tremendous and students built amazing things. The most striking characteristic of the things they built was that, compared to "manufactured" products, they were drastically simpler, because the person making the tool put in only the features they needed, as opposed to a manufacturing process that designs a tool to have an attractive variety of features to increase its adoption.

So, if we took the setup being used by Mob Programming and put the potential users at the center of the process, instead of just at the beginning and the end, and built the Mob to support their quest for a new tool, or a better tool, we might end up with tools that were much more specific (and took much less time to build). After all, a group of users that go about their daily work already is a Mob. We just need to add the power of the programming team to that Mob instead of adding the users to a programming Mob.

We can also borrow the idea of Exaptation from Dave Snowden. The users most certainly have a whole set of hacked tools to do the work that the new application is being built to do. People have spreadsheets, Access databases, processes wired together out of a variety of available services, etc. If we start by rounding up all the tools that are already being used to do the process in question, and then have the designers and programmers address their weaknesses, we have a shorter path to a useable tool, and potentially a tool that will have a much higher user acceptance.

The existing collection of tools and practices will also give a very close description of what the users find the parameters of the task to be, perhaps a much better one that we will get if we just interview the users and ask them "what do you want/need this new tool to do".

Letting users "drive" the application building process will not be an unprecedented idea. The users already built a lot of applications, because they get tired of waiting for IT to build them for them. I once worked at a State agency where they had a programmer doing an inventory of unofficial MS Access databases. Last I heard he had found a thousand of them and was still counting. User Mob Programming would just give the users the resources to build much better applications for themselves.

You might consider the process comparable to the way a Napoleonic Corps had its own cavalry, its own artillery, its own supply, and engineers. It was equipped to take on most problems it met and could call the other Corp's to its aid if it needed them.

It might be protested that the "users are to busy already. They don't have enough time to do anything like that", which should make any practicing a discipline like #TameFlow perk up their ears and guess that they are dealing with a "push" system where there is no constraint on the amount of work that is piled onto the users. Regardless of the difficulties, that huge amount of development work that is done and then never actually used should look like a big pot of gold that can be saved, and that might justify risking changing organizational habits.

#TameFlow #Lean #Agile #TOC