Skip to content

TIGER SHEEP EMPLOYEE HANDBOOK

Summary Up Front

  • We write JS/HTML/CSS web frontends that interact with a C# backend service that handles communication with SAP Business One and the database
  • We value our culture and the flexibility that being a small company affords us
  • Office hours: 0900 to 1700, let your boss know if you need to change schedule or take time off
  • Observe normal office etiquette
  • Projects are done in React, React Native, and Blueprint, or a blend of UIKit, Mithril, and jQuery
  • We talk to eachother over Slack
  • We use Gmail for email
  • We use BitBucket and Git for version control
  • You may use any IDE you want, but we suggest: Notepad++, Jet Brains WebStorm, and Visual Studio Code
  • We are in the middle of implementing Scrum

Company

Tiger Sheep works with businesses that use SAP Business One software to manage their financial, legal, and business information. SAP B1 is as complex and comprehensive as it is unattractive, and requires a great deal of training to properly configure and use. Many of our customers were never given that training or assistance in order to make good use of their business software—or even if they were, the cost and risk that comes with exposing your entire business database to those who may not need it (sales people, temporary hires, etc.) is too much to justify.

That's where we come in. We create web-accessible applications using modern web technologies and a proprietary middleman, Automat, along with a wealth of SAP B1 experience to save our customers' day. For example, instead of paying tens of thousands of dollars a year training a high-turnover sales force how to use complicated business software, we provide a streamlined sales force oriented web portal that allows those employees to do what they need to do, and only that.

While most of our customers have contracts for these frontends, many are simply in need of SAP B1 assistance and support. We have highly trained people to help with that too. In the world of SAP, there are a few businesses that provide services like we do, but none are as knowledgeable, flexible, responsive, or modern. That's where you come in.

Culture

Tiger Sheep has developed an interesting culture over the years, and we actively try to maintain that culture with who we hire, where we work, and the way we do our business. We're in a nice place just past startup, but not quite corporate that allows us to be loose with our rules, but not stressed out all the time for fear of failure. We get to say "sure, go for it" a lot.

We are a big family; not so big that you can't learn everyone's names, but not so small that we're tired of seeing each other every day. We are all nerdy about something, from video games to bicycles to music to technology. Our dream is to build our business side up to the point where we can just make computer games for most of the week, and go home happy. Our hiring strategy is to expand slowly and tend toward fresh, bright people who we feel can grow into someone awesome—not just for us, but for their development as well. In our eyes, a person who shows that they can learn and grow along with us trumps a grizzled veteran or hotshot.

Office Etiquette

Schedule, Time Off, Sick Days

Our general office hours are 0900 (9 AM) to 1700 (5 PM). You can ask to change your schedule if other hours suit you better, but keep in mind that work requirements may keep you later or bring you in earlier than those times. Please do not shift your schedule more than 3 hours in either direction, as that separates you from the "core" working hours and makes communication difficult. Regardless of your schedule, be on time. If you are running late, send your boss a message.

If you want to take vacation, send your boss a message. You are free to take time off as you need—but we can only be this flexible as long as no one abuses it. Make sure that your boss and teammates know your plans, and that any work that is due is either done, or can be handled by someone else.

Working from home is acceptable, but only as a necessity, and with an approved reason. We are not currently comfortable with allowing people to work from home regularly, but in the past it has been allowed based on the situation.

Events such as vacations and sick days need to be created on the Time Off/Sick Days/Working from home calendar. This will always be step one, granted your dates are acceptable. When in doubt, put it on the calendar.

Common Sense

Don't talk about politics, religion, sex, or other charged topics in the workplace, no matter how familiar or comfortable you are with the people you're talking with. Don't be racist. Don't be sexist. If you have to think of a clever reason why what you're doing or talking about isn't one of those things, it is, and you shouldn't be doing it.

We don't have any specific rules about foul language, but use common sense. Never swear at anyone. Never push your language too far, or use it to make people uncomfortable. Be mindful that not everyone is as comfortable with that kind of language, and anyone could be listening.

If you feel stressed out, angry, sad, lonely, overworked, underworked, or anything in between, tell someone! We'd rather sit through a potentially awkward meeting and help you out than have you suffering in a corner for any reason.

Keep the office clean. We could receive guests at any time; but beyond that, having a clean, safe workplace makes working here that much better. Pay special attention to the coffee makers (particularly if you are a coffee drinker), the sink, and the fridge. In particular, do not let your dishes sit in the sink for a week. There is no one person responsible—we ALL are.

Do your best to get your work done. You completing your projects, and pretty much everything else you do directly affects the success of the company as a whole. You're not just a drone that can get by under the radar. You were chosen to be here, and our success depends on everybody.

It is okay to screw around on the internet from time to time. We all do it, and there's no specific restrictions keeping you from anything. That being said, try your hardest to keep your slacking off to a minimum, and when you are slacking off, don't play games or look at porn at work. Believe it or not, it is incredibly obvious when your output is being affected by slacking off, and nomatter how fast you are at alt-tabbing, someone's going to see what you're looking at, and that's going to be embarrassing for you.

Security

Be aware of security risks. Those aren't just viruses and other computer problems—you also know sensitive passwords, have access to proprietary technology, and have keys to our office. Any of these and other sensitive things getting into the wrong hands would be detrimental not just to you, or the client, but the entire company.

That being said, do watch out for viruses and other basic computer problems. Do not click suspicious links. Do not download suspicious software. Do not mindlessly open email attachments. We are supposed to be technologically superior to our clients—it would look really bad if we fell victim to some basic missteps.

On the other side of things, always advocate the most secure methods of doing things that we are capable of doing, even if the client didn't ask for it or doesn't want it. Javascript can only be so secure, but we don't want to be responsible for a data breach because the client disagreed to basic password security rules. Let people know that it's dangerous to share plain text passwords, or to send company secrets over unsecured means. Odds are, they don't know what's common security practice, and will be interested to know.

Solidarity

Whenever you're dealing with a client, in person or on the phone, try to maintain the illusion that we are a cohesive unit that speaks with one voice. Companies rely on us to be experts, and to support them, or even dig them out, during tough and confusing times. Blaming other employees, gossiping, or blatantly contradicting other people negatively affects that image. Pay special care to not contradict your bosses or a project's manager/owner in front of clients for any reason.

Similarly, it's okay not to know the answer to something. The important thing is not necessarily that you know the answer, but that we do. It's always better to say "I don't know, but I know someone who does" than to guess or try to lie your way through it to not let the client down. We have many minds that have had a great variety of experiences that are always available to you - don't die on a hill by yourself just because you were afraid to say "I don't know."

Developers

As a developer, you are expected to solve problems. Most of our work is either A) solving problems, or B) making problems to solve. The odds are pretty good that you were hired for your ability to learn and think creatively in order to get those problems solved rather than any specific knowledge or experience you had.

Google It

If you are stuck, google it. Just google it. Throw away your expensive CS degree and google it like the rest of us. It cannot be said enough that knowing how, what, and when to google is an incredibly useful skill. Type exactly the thing you need into the google, receive blessings.

The Game of "This Might Not Work, But Let's Try Anyway"

But that's not all—the second part of that equation is trying things until you find the thing that works. If the most basic game of "This Might Not Work, But Let's Try Anyway" gives the answer you needed all along, but you never knew because you didn't think to actually do some experimenting yourself, that will be embarrassing for you.

If you are stuck for a while, ask someone else. A new pair of eyes, or a person to rubber duck the problem to, is sometimes all you need. Most of the problems we solve aren't unique, but some are. Those few problems that have no answers (yet) are what make us money, and what make your future resume/portfolio look good.

We are small enough that you as a developer will have to take on roles that may be separated out in larger companies. This includes IT, DevOps, design, project management, documentation, testing, etc. However, those duties only extend to our projects. If you are asked to directly do IT or any other thing that would be better handled by someone else whose actual job that is, bring that up with your project manager or boss. We as a company do not provide IT, DevOps, or QA services directly, and you are not expected to do those things barring very specific situations where they are required by your project.

Infrastructure and Tools

Every company, particularly ones that center around computers, has a secondary stack of tools used to glue the company together. We are not an exception.

Our project repos are hosted on BitBucket, which is Git-based. We communicate with eachother over Slack, which also has integrations with BitBucket to track commits. Files are shared and kept in Dropbox. We use Gmail for email. You will need to have these available and visible every day in some capacity or another.

We primarily use Windows computers. This is primarily because SAP B1 runs only on Windows, but also because Windows PCs are generally cheaper to build and maintain. If your job requires a Mac, such as for doing iOS app development, that can be arranged.

If you are a developer, you will also need an IDE to work in. This is largely up to you and what you're comfortable with, but we highly suggest these:

While you may not run into these in your daily job, or ever, we have used the following platforms and tools, and you may someday find yourself using them:

Projects

Our project stack has traditionally been as simple as possible to reduce the complexity, improve maintainability, and reduce the amount of time doing research and training. Of course, some projects need more structure and pre-built capability, and as such our projects can be put into two platforms:

React

Mostly newer projects, and with a focus on reuse and being quicker to produce. Library use should be as thin as possible to reduce the moving parts, but of course all of NPM is available to get the project where it needs to be.

Basic

Most of our older projects will be some combination of the resources listed below, as well as current/new projects that do not warrant the overhead that comes with a React project.

Of course, underpinning either platform are basic Javascript, HTML, and CSS/SASS. Remember, underneath all of these libraries and tools is just basic Javascript, which you know. None of them contain any magic you couldn't do yourself.

Knowing what platform a project deserves is important to getting the project done quickly and comprehensively. Single-function or single-page applications, or ones that are painfully simple may not deserve the functionality that React and NPM bring. On the other hand, if you already have a React project that can simply be stripped down or built upon to encompass the desired requirements, that will be a better option than starting over even if React would be overkill. Understanding that you have a toolbox available to you, and being familiar with your tools enough to know when to use them, is important to developing quality applications.

Database and SQL

Aside from the creative programming aspect, perhaps half of our job involves writing, reading, and optimizing queries. For most projects, this will be in Transact-SQL or T-SQL. For future projects, you'll have to write SAP HANA SQL queries (warning: giant PDF), which is similar to T-SQL, but with some notable (and notably annoying) differences.

In either case, you will need to get familiar with SAP's table structure, which can look daunting at first glance. There is a great SAP Table Reference that you should keep bookmarked, but the best way to learn is to dive into the database itself and start looking at and joining tables. A tiny starter hint: most of the time the only tables you care about start with "O", or have a number after them. For example, OINV is the table for Invoice documents, while INV1 contains all of the items being invoiced on each document. This pattern is fairly consistent throughout the database (exept when it's not...)

Virtual Machines

Our work generally doesn't take place, or entirely take place, on our PCs. Automat and SAP are always hosted on their own server either locally or on the client's network. In general, we prefer to set up a test environment on one of our local test servers, each running SAP and Automat. Sometimes, though, because of strange requirements or lack of time, you may have to work directly on a client's server. In any case, products will need to be deployed to the destination server, so you'll need to connect at some point anyway.

For this, we generally use the built-in Windows Remote Desktop Connection. This allows us to create a connection configuration that can be reused and shared between employees. Sometimes you'll need to use a VPN before being able to connect. Usually the credentials for the server as well as the VPN will be stored in Dropbox.

VPNs we have used include:

Nomatter where you're remoted into, always always log out of your RDP and VPN sessions. Don't just close the window. If you just close the window, your session will generally remain in memory on that server, using up resources. If you know you need to continue working on something sensitive, closing the window is fine; just be aware of the distinction.

Other Technologies and Tools

Our internal tools and functions are the secret sauce that allows us to do what we do. While this won't be a linked list you can click around in(yet?), at least it will serve as a starting point for your own questions and development.

We have done projects related to the following technologies, platforms, and companies:

Process

At the time of writing this, Tiger Sheep is currently implementing Scrum as our development process. Before that, we didn't really have anything that could be called a "process," and handled most projects on a case-by-case basis. This works for some, but for others our lack of structure and self-consistency was evident in the execution and delivery (or non-delivery) of the product. In an attempt to address this deficiency, we are looking toward one of the simpler of the Agile processes, Scrum, which emphasizes action and independence. This is fairly close to how our developers already worked, but adds a few meetings and artifacts to prop those actions and independence up.

In general, while we are implementing Scrum, it should be understood that any process we use will be molded to fit our needs, just as it is at any company. If things seem different from the source references, that is why. That doesn't mean our way is necessarily "right" or permanent, that just means that's how we've implemented it currently.

A very high-level view of Scrum looks like this: we want to deliver working, feature-complete applications as fast as possible by A) separating out job roles so you always know who's responsible for what, B) separating out tasks into workable chunks, and C) taking on only the tasks that fit within a 2-week Sprint.

If you look at any "Scrum in 5 minutes" article or video, you'll get the gist. When you boil it down, it sounds kind of like a prophecy from a fantasy book: Three roles, Three Ceremonies, Three Artifacts. It really is simple enough (from a process perspective) to summarize that easily, and that's one of the reasons it has a lot of adherence. Another reason is that it promotes and enforces Developer independence, which is a breath of fresh air if you've ever worked in a stricter corporate environment.

Let's look at all of that in the context of Tiger Sheep.

When a project is sold, we assign people to the three roles:

  • The Product Owner communicates with the client to nail down what the application or change needs to do, and organizes this into tasks on our first Artifact: the Product Backlog. They serve as the conduit between the customer's needs and the developer's needs.
  • The Development Team consists of anyone who will need to do work on the Sprint in question. This includes developers, sure, but it may also include testers, designers, support, IT, etc. There is no "development boss" or leader telling the team what to do - they meet and figure out their tasks themselves in the best way that works for them as a team.
  • Finally, the Scrum Master is in charge of making sure everyone knows their responsibilities, scheduling meetings, making sure people show up to those meetings, negotiating problems between the other two roles, and attempting to grease the wheels, remove roadblocks, and whatever other metaphors you want.

With those roles established, we begin the project. The first thing to do is have a Sprint Planning Meeting. This is where the Product Owner presents the client's needs and wants to the Development Team in the form of tasks and/or user stories. The user stories may also be written during this meeting. The Development Team processes this information and asks any questions they may have. If everything is understood, the Development Team selects the tasks and overall functionality that can be delivered, complete and tested, at the end of the Sprint. This creates the Sprint Backlog. They do this by assigning points to the stories or tasks which represent a difficulty in either effort or time. 15-30 points per Sprint seems to be a good goal for a small team, although our understanding of this relationship will better as we progress.

The point of the Sprint is to incrementally deliver fully functional changes in rapid succession. It is an iterative process, which means that no Sprint lives in a vacuum. If tasks are not complete within the Sprint timeframe, or if new tasks are discovered or requested, they are added to the Product Backlog and (most likely) included in the next Sprint. Again, the goal is to deliver something complete, usable, and useful to the customer. If that means taking a Sprint to work on one thing, that's what it means.

Every day, the Development Team has a meeting called the Daily Scrum. This is a 15-minute mandatory meeting (in that it has to be 15 minutes or less, and it has to be done every day) in which the Development Team discusses what they were able to accomplish that day, gather any questions or clarifications, and express any concerns that are getting in their way. While this is supposed to be only for the Development Team, we often include the entire Scrum Team in this because a lot of the time our Development Teams are too small to have meaningful meetings by themselves.

Once the Sprint Backlog is complete, and the Sprint is considered "done", we hold a Sprint Review Meeting. During this meeting, the Development Team demonstrates the application and the changes that were made in the Sprint. The Product Owner makes note of tasks that are complete, or not, and adjusts the Product Backlog accordingly. The entire Scrum Team collaborates on what needs to happen next. Did things turn out how the Product Owner envisioned them? Are there new tasks or requests that are important enough to take precedent over older tasks in the next Sprint? Is any part of the previous Sprint not "done", and how much of the next Sprint will it take to finish that part?

Immediately after the Sprint Review Meeting, we hold a Sprint Retrospective Meeting. In this meeting, the entire team discusses what went well, what went wrong, and anything that affected the Sprint's effectiveness. Were our collaboration tools (Trello, etc) useful? Was the team working together well or not, and why? This is a meeting for brutal honesty, because that's the only way you'll know what needs to change in order for future Sprints to be successful.

After that, the process starts again and repeats until the Product Backlog is empty. As long as each Sprint iterates on the last, and the tasks included in each Sprint are selected to maximize value for the client, and as long as the team itself is honest and transparent about the work it's doing, the process should go smoothly.

The key to these things are, again, honesty and transparency. The Scrum Team works together to defeat the project. It's not Development Team against the Product Owner and both against the Scrum Master. It's all of us against the client's ridiculous demands. If no one speaks up about problems that occur, or make good tools, teammates, and processes known, that's not a flaw in the system, but with the people, and that flaw will never get fixed.

As this is new to us, we're still figuring out how best to use this process to our advantage. It's clear that it was meant for larger teams than we have, so adjustments have been made to accomodate that. Certain role responsibilities have been blended or moved to other roles either for convenience or because that's just how it landed. In any case, the goal is to eventually approach "actual" Scrum as described by the source. Or at least, as much of "actual" as we can manage.

Scrummary

  1. Assemble the Scrum Team: Product Owner, Development Team, Scrum Master
  2. Product Backlog is built by Product Owner
  3. Sprint Planning Meeting with the Scrum Team to take tasks from the Product Backlog and build a Sprint Backlog
  4. Daily Scrum with the Development Team to discuss progress and problems
  5. Repeat Step 4 until the Sprint Backlog is empty
  6. Sprint Review and Retrospective Meeting with the Scrum Team to confirm that the Sprint is done, adjust the Product Backlog, and recognize positives and negatives
  7. Repeat Steps 3-6 until the Product Backlog is empty

Miscellaneous

  • The company's name is Tiger Sheep, not Tiger-Sheep, TigerSheep, Tigersheep, Tiger Ship, or Tigger Ship.
  • Our President's name is John-Michael, not just John. Boss is also acceptable.
  • We don't support "big" SAP, just SAP Business One, which is for small to medium-sized businesses.
  • Respect the headphone rule: one ear covered means it's okay to interrupt for social reasons. Two ears covered means save it until later unless it's important to work.
  • If you have a meeting or are going to make a bunch of noise, close your door, or move to a room with a door and close it.
  • Chew with your mouth closed —Love, Addama
  • Use your work email only for work purposes—it's not like we're keeping you from accessing your home email.
  • If you're unsure about sending an email, or are annoyed by the client but don't want to sound that way in your writing, feel free to send it to someone to tone check and/or proofread.