Entrepreneurs are key drivers of positive change. And helping them succeed is our mission.
"Some unexpected bad things will happen" - Dan North.
That quote is a great reminder of the need to hustle, to discover risks early on. To stay on the course of Deliberate Discovery.
We blend a great culture, a refined process and carefully chosen technologies and tools - to build better products.
Watch the "Big Picture" video below to learn more. Its just about 5 min long.
"It doesn't matter what you do, it matters Why you do it."
- Simon Sinek
"A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty." - Eric Ries
Considering that the environment is extremely uncertain, its smarter to accept that fact - and try to actively discover the bad stuff that's out there. Here's how we do it:
Building a Culture of Courage, Mindfulness and Constant Improvement
Adhering to (or sometimes creating) Processes that are best suited for the job at hand, and lastly
Using the most relevant and contemporary Technologies & Tools
The Exploratory Phase is about 1-2 weeks. And the Construction Phase lasts about 6 weeks.
We start the whole process with your idea. At this stage, your idea may just be a single line idea or you may have more details to share, if you’ve had a chance to invest time into the idea.
Whatever information you have available, goes as input into the first phase called the Exploratory Phase. What follows the Exploratory Phase is the Construction Phase.
Sample Exploratory Phase Questions: What problems does the product solve? Who are the Target Users? What are the key features? How long will it take to build those features?
Sample Construction Phase Questions: Are there any unexpected technological risks? How soon can we demo the first 2-3 stories? Are we getting feedback on new stories at least once every 2-3 days?
A good process, great technology and good infrastructure, are all important. But having the right team, is much more important.
There are multiple roles to be played while building a product. These include the Business Analyst, the Programmer Pair, the Designer, the Architect, the Project Manager, the Product Manager and finally, you the customer.
While that might sound like 7 full time people, they’re really just 7 roles that are played by the team.
In reality, its 5 people. Of whom, 3 will be on the team the whole time. And the others will be more like part-time consultants on the team.
And it is the above team of 5 people that comprise, what we call, a Full Construction Team.
Working software begs for feedback by its very existence - its much easier to detect communication gaps, when you can play around with working software.
How does agile work in practice? Is the solution to avoid any kind of structure altogether? And just do whatever makes sense at the moment?
Let's look at some specific questions:
How does the team manage to ship software as frequent as every 2 days or less? What about the time required to test and deploy changes?
The Agile Manifesto states that we should value individuals & interactions over processes & tools. We agree. Our tools get their jobs done well, without getting in the way of the team doing it's job.
Most of the tools that we've chosen are paid SaaS based subscription software. A few of these are free. What's common though is that all of these tools backup data securely on the cloud.
All of them are also very reliable in terms of their uptime. This allows our team to focus on the product that we're building - rather than the infrastructure required to support it. These broadly serve the following purposes: Release Planning & Tracking, Story Workflow management, Wireframing, and finally, Asynchronous and Real-Time Communication.
The most significant tool however, is our own mind. We practice what is called mindfulness at Multunus - which helps us to constantly be aware and react quickly, if and when the status quo needs to be changed.
We constantly research about and move toward better platforms and tools, while maintaining our commitment to automated tests and test driven development.
On the server side, most of the work we do is with respect to building and exposing REST based Web Service API's. As regards the client side, we build both Web and Mobile apps. And on the mobile front, we build Mobile Web, Native and Hyrbid apps on the iOS and Android platforms.
Watch this video to learn more our preferred choices in the following areas:
A typical scenario: The team finishes the first 10 to 15 stories at a rapid pace. But after that, there is usually a gradual decrease in the velocity. A key reason for this? Its Technical Debt.
What is Technical Debt?
Very simply, they're shortcuts that programmers end up taking within the code. Examples of such shortcuts include Bad Code Design, Hard-to-read code and Not enough automated tests.
Bad design results in making the code base inflexible and hard to extend - thereby making it inefficient to add new features or change existing ones.
Hard-to-read code refers to poor naming conventions and long classes & methods. The ideal case is when a programmer who's new to the code base, can figure out the system with little guidance.
Lack of Automated tests: A good code base has an accompanying suite of tests that's drives it through a comprehensive set of scenarios. When not enough attention is given to the test suite to do all of these things, technical debt starts to mount.
Push Button Deployment allows you to do everything from triggering the tests to deploying your code with just "One-Click"
The Build-Measure-Learn cycle is one of the core ideas in the Lean Startup world. The faster a startup can cycle through this loop, the better are the chances that it will be able to reach what is called product-market fit.
Reaching product-market fit starts with finding who the early adopters for the product are. Then rapid iterations of the product should be released to keep getting constant feedback from those early adopters.
That in turn requires frequent updates to the production environment with new and updated features. While it is ideal to do this multiple times day, at Multunus we do this at least once every 2 days.
Culture is defined as a set of shared beliefs, values and practices. It is when we combine these with the well researched techniques and tools, that the magic starts to work.
For us culture is about 4 things - Courage, Craftsmanship, Empathy and Reflection.
Courage: Transparency, Experimentation and a desire to Deliberately Discover the unknowns out there - even if that means failing early.
Craftsmanship: We take pride in our work too. And this includes all aspects of our work - not just what's visible to the outside world.
Empathy: Creating memorable user experiences requires the team to experience the product from the end user's perspective. This mandates slipping into the shoes of the user every so often. And doing that requires empathy.
Reflection: Practicing reflection often enough, leads to mindfulness - a state of high awareness, that is essential for adapting and reacting to changing scenarios quickly.