From startup to scaleup

Startup culture during last years have come from hype to mainstream. Business need for innovations and digital transformation added extra fuel to the mindset change. Even tech moguls like Oracle or Microsoft are adopting this innovative mindset. This change is closely related to an adoption of agile delivery methodology, since demand is to create new ideas, evaluate them quickly (via MVPs for instance) and then, either scale or fail-fast. Several unicorns have already proven the concept viable. However, the biggest challenge, as I’ve been seeing across the industry is to manage “scaling" phase and to deliver production-ready product.

Alert – excuses approaching

In my 15 years experience in development, team leadership and management of multiple product streams I’ve encountered various development processes and approaches. First real “leap" was adoption of iterative way of delivery (you can see this across multiple agile methodologies but also in for instance PRINCE2 with its stage controlling etc.). But as any other methodology in past, iterative ones are not prone to bigotry and bureaucracy as well. If scrum doesn’t work, we come up with Spotify model hoping for miraculous change, with new names for the same roles, new set of meetings and new set of “games", but still facing the same issues of lacking ownership and accountability. If our project tracking software is not satisfying (because backlog is crap), we move to another one hoping, that new tool would save us rather than going deeper and refine our specs. And so on, and so on…

Same “thing” – different product

Honestly, we faced the same problems in localhost.company. The biggest challenge has been the simplest one – to deliver product for our customer in time, in quality and in budget (you know, what I’m talking about 🙂 ). Because at the end of the day, every customer needs production ready software, maintainable, scalable and usable. After trying plethora of approaches (Scrum, Kanban, Scrumban, Lean) we realised, that we’ve been missing something. So we step back a little and look on agile manifesto again, but this time as an “interface" to implement, rather than implementation. This approach brought us more “mental space" for manoeuvring and ability to incorporate principles from various sources like Management 3.0 and my favourite Gyshido (Get your s**t done – https://www.gyshido.com).

One goal to rule them all

Embracing rule to “inspect and adapt" completely, boosting people motivation and having absolute focus on finishing your stuff, we call our approach “zero-to-one" (yes, similarity with Peter Thiel is not coincidence). In essence we create delivery “framework" per project, because every project is specific – there is specific set of people in the dev team, specific timeframe, specific technologies, specific product and every customer is specific too. So all the aspects of such tailored delivery approach like people management, project governance, customer expectation management etc. is primarily dedicated to one ultimate goal – to deliver!