Bamboo takes an ultra-lean approach when working with clients, focused on bringing exceptional value without the bloat of traditional software firms.
Other software firms throw a team at you:
Bamboo, in contrast, hands you over to an elite pair of Software Consultants.
A Bamboo Software Consultant is not only an expert software developer. He is also:
We'd prefer to use a single Software Consultant per client project, except it's too risky for our tastes. What if he gets sick? Or wins the lottery and quits? Or goes on vacation? To mitigate this risk and to offer the benefit of diverse thinking to our clients, we use pairs that alternate between projects rapidly.
What does this look like, in practice?
Will my project take longer to finish with only ONE person working on it at a time?
Surprisingly, no.
Software, especially greenfield software, is more like a baby than a ditch. If it takes 1 man 9 weeks to dig a ditch, 9 men will probably get it done in about 1 week. But you can't get 9 women to incubate 1 baby in 1 month.
It has been understood by the software industry for a couple decades now that the building of software cannot be scaled similarly to labor-intensive activities. Instead, adding too many cooks to the kitchen ends up slowing things down and leading to poorer code quality. Experts, in particular, are able to move VERY quickly when left alone. Some of the greatest pieces of software were built by lone experts.
It also significantly simplifies communication between developers and the client, making that part of the process much more efficient and pleasant.
But what if I want to increase capacity on my project because it's HUGE?
If it's really enormous, then it probably isn't actually a single project to begin with. Let's discuss how we can break it into smaller chunks that can be safely developed in parallel. We have great relationships with other top-notch development shops and some external individual contractors, and can work together well on truly large projects.
But FYI, this is rare.
Aren't software guys super nerds that don't like to talk? How could they ever be effective project managers?
Typically, perhaps. But that's why Bamboo is different. We hire the complete package specifically with the goal of organizing our process in this way. Speaking, writing, and listening clearly are just as important for our candidates as is writing clear software and designing clean interfaces.
I don't think we're having enough meetings, could you schedule more?
Please no. Nobody wants more meetings.
We pride ourselves on working "asynchronously" as much as possible, only using full meetings when truly needed. Our clients love it, and so do our Software Consultants. Writing good software is a complex activity that requires extended periods of uninterrupted blocks of time to avoid "context switching". Limiting meetings, therefore, is a key component toward delivering high quality software with optimal efficiency.
Despite despising most meetings, some are necessary. A large part of what makes our ultra-lean process work is our emphasis on effective fluid communication.
What does this mean?
When we have questions, we'll usually send you a Slack message. This is asynchronous communication, so you can reply when you're able to and don't need to context switch yourself.
Every day, we'll have a 5-15 minute meeting between the client and the Software Consultants, with the purpose being to demo to you the work that was done the day before, gather feedback on it, and verify that the priorities are properly set by you for next steps. Sometimes, even a meeting isn't necessary and so we instead send quick videos showing a demonstration of the recent changes. Your feedback is appreciated in the form of Slack or email, or if it makes sense, via phone/video chat.
The most important thing is that communication is frequent. Software projects die when there's a giant planning phase up front, after which the devs disappear into their dark holes only to re-emerge with software that is not at all what the client originally expected. Communication is hard, and precise communication is very hard, especially when the scope becomes much larger than tiny. By keeping communication frequent for tiny short bursts, we limit the risk of things drifting off track. This significantly reduces wasteful work, enabling us to operate ultra-lean.
Rapid Feedback is really under the umbrella of Fluid Communication, but it's highlighted by itself here because it's that important. A client's software project WILL FAIL if they're unwilling to participate in the process.
The client is the expert on the software and what it needs to do.
Rapid client feedback is essential.