Georgia Institute of Technology (Georgia Tech) researchers found insights into ant cooperation could be incorporated into the development of large swarms of robots. The team first placed 30 ants into a container filled with glass soil-like particles, and observed only 30% of the ants performed the majority of the tunneling. They then tested similar strategies with four excavation robots, only to find that a four-robot team kept causing congestion unless at least one robot remained idle. Georgia Tech’s Daniel Goldman says the implication is that when groups of individuals cooperate, the best strategy may be for some to hang back. This knowledge might help inform the design of software for controlling robot swarms. Goldman aims to apply ant behavior dynamics to the coordination of large robot swarms in confined spaces. New Scientist, Timothy Revell, August 16, 2018, Future Robot Swarms Should Copy Lazy Ants Who Let Others Do the Work.

It was a scrum. No, not the agile software method, but a bunch of people all racing after the current big defect found in the product. It was a badge of merit to be the first to figure out the defect and to report on its fix. My boss expected me to jump into this competition of egos when these problems happened. Instead, I figured we had more than enough people chasing these defects and I worked on other things important to the project. While avoiding the classic rush for recognition and reward I researched and developed trends and statistics on all these defects we found on each product (around 15K defects or issues were reported per product). I came to understand and recognize the phases a defect would transition through. From identification to reproduction to root cause to a fix coded and tested and finally to the fix merged and tested into the product. Each phase took a certain average amount of time and this time distribution varied predictably over the duration of the project.

See defect reports are your best friend.

When all the ‘robots’ (managers, engineers, programmers) jumped on to the same hot task, they would start to get in each other’s way and start to thrash. Unlike the robots, these people would also often feel incentivized to get in each other’s way. Knowing when not to throw more people at a task and then to use those resources to solve other problems was just plain good project management. With me not jumping into the fray, we instead learned that typically towards the end of the project it might take seven days to resolve a defect (reproduce, root cause, code fix), and seven more to merge and regression test into a product build we would then release for customer testing. While we still needed some people chasing the big defects, knowing when any given defect would probably be completed allowed us to objectively manage the overall project without having to worry excessively about every reported defect. It was quite annoying to many people that using the averages I would consistently better predict when something would be ready for the customer than all the detailed analysis produced by the hot, sweaty, and sleep deprived, managers and engineers.

See further optimizing your staffing by knowing your staffing numbers and who are your turkeys and eagles.

Are you applying staff to problems in a way that is actually productive and not prone to wasting resources or causing unintended conflicts?