How to get results effectively in your engineering side job with Agile practices

Key takeaways

  • Agile philosophy and practices helped a lot in my side job, even if it’s a one-person project.
  • Alexander Laufer’s categorization, which is means uncertainty and end uncertainty, helps to design your way of working.
  • Shorten the iteration to get feedback for your work frequently by dividing your task into detailed user stories.
  • If your task has high technical uncertainty, it is also a good way to add an additional phase where focuses on investigating technical issues.
  • If you wish to work with more discretion and initiative, do self-management.

A difficulty to get results in an engineering side job

Previously, I published the blog sharing that I’m joining Autify, which serves as a no-code AI-powered software testing automation platform, on January 1, 2022.

In fact, I had worked at the company as my second job for a few months about 40 hours per month. Then, I joined this company this year as a full-time employee.

Based on this experience and my former experience as an engineering manager supporting new employees into my team, I would like to share my thoughts on how to get results in a short time as a side job engineer.

If you work as your second job, you probably don’t have much time available because you have your primary job during the daytime. In my case, the longest month was 40 hours, and the shortest month was only one month. That’s why you need to produce steady results in a short time. To work well, agile philosophy and practices helped a lot in my side job, even if it’s a one-person project.

In this post, I will introduce four techniques to get results in a short time as a contractor.

  1. Shorten the iteration to get feedback frequently
  2. Self-management
  3. Prepare in advance for the first kickoff
  4. Transparency at your work

1. Shorten the iteration to get feedback frequently

Needless to say, you don’t have much time to work the side job compared with the primary job. I suggest you develop your work in a short period of time in order to get feedback on your work frequently. This idea is based on the principles behind the agile manifesto proposed by Agile Alliance.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Alexander Laufer groups uncertainties into two categories in his book Simultaneous Management: means uncertainty and end uncertainty. Means uncertainty refers to uncertainty about exactly how we will design and. develop a product; end certainty refers to uncertainty about exactly what a product will do.

As a person who joins as a side job, you will probably be assigned to tasks that are expected to have less uncertainty, especially end uncertainty. Still, if you show the finished work without showing the progress along the way, you may end up creating something that is misguided!.

There is less first-hand information available to you compared to a full-time employee. For example, your working hours would be irregular, such as early mornings and evenings, that’s why it tends to be difficult to get frequent syncs on the daily or attend the team meeting. In addition, your scope of access to the code repository may be limited to the minimum necessary, or the range of the slack channel may also be limited.

You may make mistakes that you would not make in your primary job if you don’t actively acquire information.

To reduce means uncertainty, you need to get feedback for your approach to solve your task. In the case of service feature development, it is important to take into account how they work for service reliability in the production system, how they support their customers, the system of manning, the future outlook of the engineering team, and etc. One of means uncertainty is that it is a little bit difficult to obtain first-hand information about these production issues. You should get feedback about that in order not to end up with a low-quality design.

Also, to reduce end uncertainty, Your understanding of its requirement should be checked by showing the progress along the way. The situation is ever-changing, and something more important than the first requirement you were told might appear. Since you may end up making decisions that do not align with the product vision, you should get feedback from one who has a deep understanding of it frequently.

There are two specific techniques: to divide into detailed user stories and to add an additional phase where the technical investigation is the main focus.

If you are working on a relatively large project, break up your user stories into smaller pieces and demo them at a sustainable pace. Needless to say, if you are familiar with user story practices, it is important to keep them “vertical slice”. The term “vertical slice” refers to a cross-sectional slice through the layers that form the structure of the software codebase with emphasis on demonstrating progress across all components of a project.

Quoted by

It is also a good idea to have regular demonstration meetings such as the sprint review in Scrum.

If it is a relatively long-term project that may take more than 3 months and there are several uncertainties due to technical difficulties, it may not be efficient to continue to produce user stories at the production level (i.e. writing automated tests and doing other manual tests), in each iteration. In that case, it can be a prescription that you add the phase such as PoC (Proof of Concept), prototype and etc.

Divide one phase into two phases: the PoC phase and the developing for release phase

I don’t care about the difference between the term “PoC” and “prototype”, but the important point is that each Definition of Done is different. The term “Definition of Done” is well known in agile development. It offers a compelling image of well-defined slices of a product and provides a checklist that defines the minimum work generally required to get a product increment to the “done” state.

In order to create deliverable increments that are ready to release to customers, you will need the following checklist (it depends on your team).

// Definition of Done (for the development for release phase)
- [ ] Can demonstrate the function or code?
- [ ] Got at least one approved in the code review from team members?
- [ ] Wrote automated tests to check whether your code is working?
- [ ] Story acceptance tests is passed?
- [ ] Updated the design document (if necessary)?

This checklist can be an obstacle when conduction technical investigation under high means uncertainty. It is difficult to create test scenarios with a high level of technical uncertainty, and even if you write automated tests, there is a possibility that they will be discarded soon, which is expensive (If you are a TDD practitioner even when you are implementing a PoC or prototyping, this may not be the case). In my case, the definition of done in the PoC phase is as follow:

// Definition of Done (for the PoC phase)
- [ ] Can demonstrate the function or code?
- [ ] Updated the design document (if necessary)?

The demonstration is important for discussion and getting feedback for the product specifications, so it can NOT be left out here. However, I decided NOT to test with the production release in mind, assuming that I will rewrite it after the end of the PoC phase.

In a sense, this can be rephrased as making time to work on spikes for a long time. Spike is the name for a timeboxed user story or task that is created in order to research a question or resolve a problem. It focuses on gathering information and finding answers to questions, rather than producing a shippable product.

As a reminder, it is important to agree that the artifacts demonstrated in the PoC phase cannot be used in the production environment as-is. Rebuild it in a way that meets the definition of done for the next phase.

Also, if you can just put spike issues in the normal way, that is better because it’s the simplest way for you.

2. Self-management

When you are welcomed in a new team, your manager has the first, second week to think of “what kind of management should give you?” and figure out which category’s issue give you.

2x2 diagram (end uncertainty, means uncertainty)
2x2 diagram (end uncertainty, means uncertainty)
  1. Should give you a clear problem and solution (low end uncertainty, low means uncertainty)?
  2. Should give you only a clear problem and let you think of a solution (low end uncertainty, high means uncertainty)?
  3. Should tell you product concerns, and ask you to clarify a problem to be addressed and think of a solution (high end uncertainty, high means uncertainty)?
  4. Should give you a clear solution and ask you think what is our problem (high end uncertainty, low means uncertainty)?

If you wish to work with more discretion and initiative, you should show the kind of stability that allows you to tackle issues with higher uncertainty.

Self-manage so that you need almost no support in your work. Self-management skills are the abilities that allow people to control their thoughts, feelings, and actions, for example, in the following areas:

  • Organization: plan, prioritize and execute important activities
  • Goal setting: determine what you want to achieve in a clear and well-defined manner
  • Time management
  • Self-motivation: take initiative and finish tasks
  • Stress management: handling stress
  • Accountability: take personal ownership of your thoughts and actions

Be proactive about these. In my case, I try to get people to review the decisions I’ve made, rather than having them decide. If you are a person who does not bring your own opinions to that table and let others decide for you, they may think that you need to manage your work in more detail there.

In fact, since a contractor position makes it difficult to take responsibility to some degree, the final decision needs to be made by a person such as a project owner, etc. However, as long as you are involved in the product development, you should have an opinion. You can say “There are several choices, and I think choice A is good for you because…, What do you think?”.

3. Prepare in advance for the first kickoff

As I mentioned the above, in the first or two weeks, your manager will determine the appropriate level of involvement for you. You’ll be given the overview and details about your job at the first kickoff meeting, but try to prepare in advance as much as possible. In particular, tasks entrusted to contractors will often not be specific to their product domain deeply, but rather issues in more generic technical area. The better. your understanding of the task on the first day, the more likely you are to get tasks of higher difficulty afterwards.

4. Transparency at your work

Make sure that other members can see what you are doing and thinking, because you’re not working synchronously. If your workplace uses Slack, it’s a good way to create a #times-xxx channel to open your working. Also, the skill of documentation is very important for remote-work as GitLab mentions at the guide about their remote work culture.

The Remote Manifesto:

3. Writing down and recording knowledge (over verbal explanations).
5. Public sharing of information (over need-to-know access).
6. Opening up documents for editing by anyone (over top-down control of documents).
7. Asynchronous communication (over synchronous communication).

As a manager, they are concerned about whether your work is not dependent on individuals. You work will be asynchronous and remotely, so write enough amount of documentation and publish as much information as possible!


I explained four techniques to get results in a short time as a contractor.

  1. Shorten the iteration to get feedback frequently
  2. Self-management
  3. Prepare in advance for the first kickoff
  4. Transparency at your work

I wish you all the best in your work!




Love podcasts or audiobooks? Learn on the go with our new app.

Best of the Week — May 30 / June 12

The Last Leg of the Trek

2021 Maschsee Triathlon Hannover’ Livestream | LIVE° [Fullᴴᴰ]

Client Authentication with AMQ Stream Operator #1

Create uniquely beautiful forms, true to your brand with Quest

Create uniquely beautiful forms, true to your brand with Quest

Interviewing at Vidmind

2. Best Time to Buy and Sell Stock II

How to setup your Intellj IDEA project for Selenium web driver

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kazuki Higashiguchi

Kazuki Higashiguchi


More from Medium

Agile Project Management

Small steps to improve your async scrum meetings

Benefits of The Agile Development Methodology —Post by Meeraki Software Solutions

Agile Quickies: Deliver working software frequently