Here's a scenario you might have encountered.
You have a fairly small change to a product or service, maybe a small internal product that will provide some efficiency to your larger organization. You decide you need a developer but not full time, of course; just someone who can work on your product in her "spare" time. You know the lead time and the level of interest required to get a Team approved by the development manager is probably just considered overhead.
The worst thing that can happen is your leader gives you permission to ask the dev manager, who then gives you permission to talk to the developer. You go off and have that conversation, and the young developer, fearless in trying to help people solve problems, agrees to support you. You make great plans, set some expectations and then your dev "Wonder Woman," enthusiastic and, at the moment under-tasked, is off to a great start. You get something that is almost good to go. It just needs a little more testing and maybe a few tweaks.
Then it happens: the dev manager throttles Lynda Carter's time for your project because of the FY close-out initiative for the updated TPS report format. But all is not lost; the dev manager agrees to have Timmy help. So Timmy gets the code from your first prospect and spends a lot time understanding it, and you and Timmy review almost all the conversations you had with the first developer. Timmy makes some updates, "refactors" a few things, fixes a couple of the bugs and then is ALMOST ready to hand you something when the TPS reporting engine has to get updated to use an open source framework (which is waaaaaay cooler than your tool)…and so on, and so on, etc.
The flaw here is thinking that a coder is faster than a Team.
There is a quote floating around that says, "If you want to go fast, go alone. If you want to go far, go in a group."
In the scenario above, if you had made a good business case, you would have been better served to get a small Team dedicated to solve your business problem, incrementally and iteratively. While it can be true that smaller projects get shoved aside, in disciplined, moderately mature agile delivery environments, Teams can take a break from their regular value stream to work on smaller things.
Sometimes the break makes sense because the larger value stream has an input (well-groomed backlog problem) or output (the production environment won't be ready for weeks [Ugh!]) problem and it just doesn't make sense to code things we can't use. Sometimes a Team just needs a change to break a cycle of limited improvement. This can happen when the Team has been working on the same business problem and space for an extended period of time.
Creating the opportunity to have smaller projects the Team can deliver incrementally and iteratively is a great way to flow value. The Scaled Agile Framework (SAFe) builds in this concept with the Innovation and Planning Iteration, a great opportunity to have Teams work on smaller things, including development, that simply make things better, or try out new ideas. If you're not using SAFe you can try adding HackAThons, Mob Programming days, or other ways to give Teams the opportunity to work together outside of their typical product backlog.
Why not just give individuals time to work alone? At the core of the agile framework is a cross-functional, self-organized Team. We still have a long way to go to ensure that everyone is thinking "Team-first" when we assign projects; keeping a Team together, particularly for the small things, will foster the Team-first mentality in both Team members and those who want to give them opportunities to be great.
To modify the quote from above:
