Agile at Big Room Technologies
It may seem like software engineers speak a foreign language. And we say that lovingly on behalf of our designers, project managers, product managers and operations team!
Most of our clients are non-developers. They are absolutely brilliant, and know their company inside and out. But they aren't used to the alien and confusing syntax that software developers speak. While client education is important to our process, we also educate our developers on how to communicate with clients, regardless of whether they're showcasing a project for C-level managers or collaborating with interns.
Creating a common language that both developers and business people can speak/understand is necessary for a successful collaborative project. Every failed project can attribute at least some of the results to miscommunication.
About a decade ago, we moved away from using a traditional waterfall approach to project management and started using Agile development processes. This move gave developers the flexibility they needed to iterate and make a better product, and business people to be able to manage and assess timelines, milestones and budgets.
Our goal is to give clients what they actually want, not just what they approved in the contract.
Our style of Agile has changed to accommodate our client needs and internal processes. We've realized that there were pieces of the process that worked awesome, and some parts still felt like going through the motions and wasting time. We started to slim down our process and become even more efficient, taking the parts of Agile that work for us and not feeling obligated to keep the parts that didn’t. We incorporated a lot of the ideals from the Lean Startup and from our experiences with the Google Design Sprint workshops.
We aren’t dogmatic about the way we do things, but we have borrowed from the style, ideas, and language of Agile and Lean processes.
If you're ever wondering why the heck we're doing something - it probably comes from our belief in these things:
People and relationships over processes and tools.
Working software over bloated documentation.
Client collaboration over contract negotiation.
Responding to change over following a plan.
Don’t make any assumptions.
Test everything!
Build, measure, learn.
