Jan 11
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.
- Shorten the iteration to get feedback frequently
- Self-management
- Prepare in advance for the first kickoff
- 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.
Divide into detailed user stories
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.
It is also a good idea to have regular demonstration meetings such as the sprint review in Scrum.
Add an additional phase where the technical investigation is the main focus
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.
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.
- Should give you a clear problem and solution (low end uncertainty, low means uncertainty)?
- Should give you only a clear problem and let you think of a solution (low end uncertainty, high means uncertainty)?
- 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)?
- 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!
Conclusion
I explained four techniques to get results in a short time as a contractor.
- Shorten the iteration to get feedback frequently
- Self-management
- Prepare in advance for the first kickoff
- Transparency at your work
I wish you all the best in your work!
