More info is needed before criticising on the fact that the team wasn’t brought along, that buy-in should have been arrived at.
I saw successful cases when a sole person (sometimes but not always me) undertook a solo sprint, over a vacation or holiday period, or otherwise in isolation of the others. I also saw a case when the need for a pivot was a shared sentiment, and there were multiple new hands and common enthusiasm as well, yet the teamwork aspect fell through the cracks because only I as the most driven person (I was asked to lead i.e. be responsible, plus some bonus stake) ended up working through the holidays while no one else did anything despite earlier interest and consensus (yes I asked mgmt that crunchtime bonus should be for all hands).
In one case, a young coworker developed code around off the shelf libraries which cut down runtime from 30min to around 20s, with better results and 1/10 of custom code size.
There can be a bunch of reasons for going it alone:
- the skunkworks is risky and not worth confusing or disorienting the team unless at least a promising proof of concept is in place
- there may not even be a consensus or shared sense of necessity to rework something; the person taking the initiative may more efficiently put time into showing and demonstrating rather than telling, ‘influencing’ or rectifying past management behaviors
- some people on the team, or someone sideways in the organization may be inclined to be detractors or naysayers — who of us haven’t heard of projects that suffered or died from friction or attrition
- even with positive attitude and support from everyone, sometimes there’s enough distilled knowledge of what worked and what hasn’t, and what the domain specific problems are, that it’s just more efficient for one person to beat the path for whatever time is needed serially, rather than trying to go wide and team-spirited but losing a lot on task partitioning and communication for what evidently was within the capacity of a single, well prepared person
- a different prototype, as in this case, may need few if any of the specialists such as a graphic designer — at least it’s likely that the designer’s contribution can be added to an already working prototype if it’s indeed just icon etc. design
- budget — money and/or time
- it can be handy that there is more than one iron in the fire; should the skunkworks effort fail, business is as usual, or chance for a more educated pivot; should the main dev path continue to falter, the simpler, leaner base will be handy (or even save the company)
- secrecy — a skunkworks project may be a radical attempt at winning a strategic customer or investor prospect held in secret, i.e. ‘go’ if presales is successful and maybe throwaway if it isn’t
- responsibility and motivation of a single, highly vested, skilled person may lead to higher sprint productivity than looping in employees
Sure, some of these shouldn’t happen in a well run organization but it can’t be taken for granted, e.g. in this case.
Shared work is usually preferred, but for us outsiders it’s hard to tell if it had worked out for their situation, or it had worked out for them only if the realization and pivoting actions had been made much earlier. Depending on the prevailing company culture, attitudes and traits, a quick personal sprint may sometimes be less damaging or more inspiring to some.
Last, sometimes a piece is best conceived and performed by a single mind in a creative process. This goes without saying in a lot of branches of art. But even in the software world, so much of the great stuff stems from spirited and focused work from a single individual. Think of Linux, Python, Redux, Elm, Clojure, and probably most of git repos. Sure they became team efforts later, but a single person’s focus is a different creative process from that of a coordinated team effort that prioritizes buy-in and focuses on people, therefore the results are different.
