This document attempts to describe how Futureworkz employee behaves together as an organization - how we think, how we talk, how we respond, etc. The main purpose is to align everyone in Futureworkz to work together, be happier and spend more meaningful time in work while producing a profit to sustain and grow the company.
Futureworkz is a company and like every company, Futureworkz needs profits in order to survive and grow. Futureworkz relies heavily on the people working in it in order to generate a sustainable profit.
We strongly encourage any employee of Futureworkz to improve this playbook by submitting a pull request (for coders) or raise an issue (for non-coders).
This playbook is not made for you, it is made from you.
We accumulate knowledge capital and skills in startup industry in areas of marketing, UX design, IT development and technologies.
We then sell this knowledge and skills to clients as business consultants, project management, design and development.
Through this cycle of learning and applying, we grow into Asia thought leaders and a world class development firm.
Clients will then naturally engage us over other competitors despite our premium fees.
noun
a worker in a skilled trade, especially one that involves making things by hand.
We are no different from a coffee barista or a carpenter who rely on their skill and experiences to create a beautiful and functional coffee or chair for their customer.
We create web/mobile app through our Agile thinking, coding and design craftsmanship. We are craftsmen, creators, partners, consultants and sometimes saviors to our clients. The final product launched on the web or in mobile store represents who we are and our craftsmanship.
We are app artisan.
To be a happy software development firm
with happy employees
for happy customers
by happy bosses
As our industry is a fast learning and ever-changing industry, a learning culture between management, staff and client is a necessity to our survival.
Learning is not just accumulating knowledge. We apply them, experiment them, play with them until we understand them. A learning culture is not just a culture with lots of presentations to attend. It also encompass the curiosity to experiment and the dare-ness to fail.
Management has the understanding that mistakes must be made in order to learn new things while employees take the initiatives to learn, experiment and share new things in Futureworkz.
While we have our daily work and deadlines to meet, we strive to learn on the job (eg. trying a new Ruby gem) or spend after-work time (eg. attend a Ruby Meetup) to advance ourselves.
We also constantly strive to present what we have learned so that others may benefit from us.
There is always a better and newer thing in the Internet. We should not stay entrenched in yesterday’s thinking. It is okay in Futureworkz to try something new and fail horribly. In fact, we know that most of the time, the newer things will probably fail but that once in every while, we will find something that is really great!
We are active learners and do not shy from anything new. We also recognise that the best way to learn is to teach. Through teaching, we share our knowledge. We are not afraid that our knowledge is wrong or too low. We are only afraid that our mind is closed from learning.
Without vision, we are lost. In whatever we do, we always strive towards being the best in the world. We love best practices, best ideas, best methods, etc. We actively research and adopt best-er practices in our work to improve our skills.
No knowledge in the world is useful until it can be applied. To apply knowledge, we need discipline in our work and in our life. While we can be crazy and unorthodox in our thinking, we exert discipline in our execution and conduct.
To give you a better sense of how we work in Futureworkz, here's some things you can do:
- Things are always changing internally due to improvements, so get used to new ways of working
- You can share our opinions openly and honestly
- You can talk back to your bosses because they value your ideas and opinions
- You should take initiatives to improve yourselves, the company and the world
- You can talk loudly and even laugh loudly in the office
- If you solve a huge coding issue, share your success with others by proclaiming loudly in the office
- If you want coffee, ask others (including your bosses) and order together
Steven Yap is the CEO and CTO of Futureworkz. Primary main responsibilities:
- To train 10 XP coders
- To provide IT and business consultation to clients
- To ensure a growing working environment in Futureworkz
- To provide vision and direction for Futureworkz
Lawrence is the COO + CFO of Futureworkz. Primary main responsibilities:
- To manage the financial status of Futureworkz
- To manage the Vietnam operations
Changs is the CMO of Futureworkz. Primary main responsibilities:
- To develop new business units
- To provide IT and business consultation to clients
- To ensure a viable marketing and sales process
Sujata is the Project Manager of Futureworkz. Primary main responsibilities:
- To ensure project development is on track
- To resolve project development conflicts
James is the Lead Software Engineer of Futureworkz. Primary main responsibilities:
- To guide & support the technical aspects of projects
- To support the continuous education of coders
- To push new technologies adoption in Futureworkz
Futureworkz will only engage a project if
- the project will enhance our reputation in the industry
- the project enhance our knowledge capital in terms of implementing new technologies
- the project is profitable to the company
We use Agile eXtreme Programming (XP) to run our projects. Coder will be assisted by AE to communicate directly with the client and complete the project. PM will oversee all projects and mainly to provide outside scope communication and consultation to client.
We see PM and AE as the interim solution to reach our ideal XP goal - where every coder can manage the project, code and even provide consultations directly with the client alone.
Our ultimate goal is to create XP coders who are not just able to deliver superb coding but also able to manage a project independently and directly with the client and also to provide consultation to the client.
As client pays us by time, it is important that we demonstrate the integrity of our development time in order to avoid disputes such as whether our coder is working or not.
We use HubStaff.com to monitor every coder’s working computer to ensure our working hours are fully devoted to the client’s project.
To prove our integrity, we allow client to view our coder’s screen upon request.
We do not believe in rushing for project and working overtime. We believe in working sustainably and balanced so that we are a happy bunch of sane workers.
Software requires good brains to create good codes and good processes. Working overnight destroy productivity, happiness and quality. Why should we produce low quality product for our clients?
Dress as you like - nudes are welcome too.
We have high regards for code quality in Futureworkz. Code quality affects speed of development, maintainability and coder's happiness.
To maintain high quality coding standard in our app, we do regular code review. We also conduct a Ruby evaluation test every alternate Saturday 9am.
We view the education of our coders seriously.
Coder in Futureworkz starts with getting familiar with our drills. Through practicing our drills, coder understands Futureworkz coding standards and practices.
Futureworkz adopts a code review practice for all development work. Coder will learn, teach and reinenforce best coding standards through the code review sessions with each other.
Tea break presentations happens on every Monday, Wednesday and Friday during the tea break (320PM to 340PM). Tea break presentations are short 20 mins Ruby presentations where all coders learn from each other on Ruby knowledge.
Futureworkz hosts the Saigon.rb Ruby meetup in our office on the first Tuesday of every month. We see it as a way to give back to the Ruby community as well as another learning channel for our coders.
Finally, we evaluate the improvement and development of our coders through our Ruby evaluation test. Evaluation shows the improvements in our coder's education in Futureworkz.
If stuck, google by yourself for 10 mins. If no solution found, ask someone. If a solution is found, implement it but don’t waste more than 30 minutes to implement the solution (it may not be the correct solution). If you found a really great solution, share it!
We follow a simple step-by-step flow to complete our project:
- Clarify story requirements and start the story in Pivotal Tracker
- Break into steps
- Write test case for a step
- Write the passing code
- Refactor the code
- Run full rspec
- Commit the code (in development branch)
- Repeat step 3 until the story is completed
- Merge into master and checkout development
- Push to staging and mark story as deliver
- Test staging
- Mark story as completed
Client hires us to develop their best ideas. We should ensure that the code and other intellectual properties are not leaked to the public or worse, client’s competitors.
While it is important to be secure, it should be balanced off with productivity and efficiency. We believe in our employee's integrity and professionalism. As such, we maximise productivity while keeping the intellectual property secured.
Some basic rules we practise are:
- Never push project source code to public repository
- We can share snippets of code but not all of the code with other parties
- We can discuss what we learn with others but never reveal exactly how it works
The product owner is the person who is in charge of making the decision for the app. This is generally our client. In the event where our client has a team of more than one person, we would ask for a single point of contact from the client's team and that person will be the product owner.
Ideally, the product owner should be available via mobile or online during development hours. Practically, we ask for at least one hour a day with us.
The product owner is expected to:
- Clarify requirements
- Test and approve/reject developed stories/design in Pivotal Tracker
- Guide us in decisions on the app business direction
We believe client should know how to manage their own IT assets so we require the product owner to register any needed services by themselves such as Amazon Web Services, Google Analytics, etc.
After client has signed our quotation, a meeting (known as inception) is conducted before development can start.
Inception is a two day meeting in which all stakeholders gain alignment in the team. The stakeholders typically includes client, end-users, designer, coder, project manager, and consultant.
At the end of the inception, we will have the initial stories to start development and design.
We use PivotalTracker.com to track all the progress of the stories. We prefer it because it allows acceptance and rejection of the stories clearly.
We begin with wireframing the user layout and interface. We focus on the most important workflow first and the stories in swim lane #1. After the wireframes, we will flesh it out with the visual asthetic design.
Development begins on the highest business value stories or the riskest stories. We want to deliver high value stories to client first instead of wasting time on low value stories.
Developing the main workflow or the highest business value stories first will validate the idea of the project quickly and easily.
We start every project with a great inception meeting and we should end every project with a proper closure procedure.
The project closure is to ensure:
- All important information such as the source code, credentials, etc are accounted and stored properly
- The project can be re-deployed easily again in another environment for further development, maintenance or bug fixing
- If we open the project again in the future, there will be enough information for us to start work in the minimum amount of time
Our project closure procedure should be completed in one man day.
For production sites, there are several 3rd party services which we highly recommend our clients to use. Most of them are free (at least for low volume). Client should sign up the 3rd party services themselves and then pass us the account to integrate for them.
| Services | Website | Price | Why We Recommend Them |
|---|---|---|---|
| Google Analytics | http://www.google.com/analytics/ | Free | Google Analytics is a freemium web analytics service offered by Google that tracks and reports website traffic. |
| New Relic | http://newrelic.com/ | Free (for Lite) | New Relic collects all the data and performance of your software. If Google Analytics is frontend, New Relic is your backend. |
| Gemnasium | http://gemnasium.com/ | Free | Gemnasium parses your project's dependencies and notifies you when new versions are released or they need to be updated. |
If there are more man days available and client approves, we will do a final code review on the entire code to see if we can improve the code quality further.
This stage is optional since code review is done at various lifecycle of the project development and subjected to client's approval.
We will update all the gems and dependencies to the latest version so that the app has the latest security patches. For Ruby on Rails web app, this means running bundle update
We will then deploy the latest updated dependencies to the staging and production to ensure that it is running smoothly.
We will update the Readme.md to give a general overview of the app. The purpose is to reduce the ramp up time for the next developer to maintain or develop the app.
Note that the Readme is only an overview and the documentation of the app is in our test cases which you can see by running rspec -f d.
A sample README.md file can be found here.
We will do a final check that all sensitive information such as login, API access tokens, etc are kept in a secured but accessible location.
Our system administrator will do a full deployment separately to ensure that all required information is present.
We will archive the source code, design files and other assets into a common repository for easy retrieval later. This ensures that we will be able to service our client in events of maintenance or ad hoc jobs or future development.
We will send all the source code, design files and any other information to the client using wetransfer.com or slow mail in a CD. We will also send a nice see you again email together with a discussion on maintenance package.
We are continuously improving and changing - so is this playbook.
To keep yourself updated with this playbook, you can star this repository and you will be able to receive updates on this playbook.