Tech is full of challenges, but probably one of the most difficult is scalability (in every aspect).
And this is becoming harder when the team is growing up.
Here is the point: How we can continue to ship fast with the same level of quality when the team becomes bigger.
We all often, if not always heard about Agile methodology, and why agile is the way to go when you are working on a project, this is even more true when this is an IT project.
At Kiute, we chose to create a strong culture based on the concept of build-measure-learn feedback loop rather than blindly use framework or methodology.
We strongly believe that responsibility and confidence are the key to a successful team, and on the other hand, adding processes as we scale seems to be a good idea but it slows down project flow adding an infinity numbers of Agile gurus, endless meetings, paperwork….
Do first, understand later
Joy of experimentation
Learn by doing, is much more exciting than read, try to remember and maybe later test it.
A lot of developers are doing this, and even those who said no are doing this.
Who already use a promise in JS, without knowing how it works behind ?
Use goroutine or threading abstraction without knowing what is a thread and how it works ?
It contributes to productivity, fuel the thirst to learn
I spent weeks to feel comfortable with promises, and didn’t know how Node.js handle it, I heard about “async loop” but that meant nothing at this time.
When I knew how to use promises by coding, I felt excited, and wanted to learn more, this is where I learned how Node.JS single threaded loop could handle asynchronous features.
Easily reversible
Most in software industry the cost is lower than other ones, this is “just” lines of code, also you can try and test until it “works”, by nature this is a part of the process.
Seasons
Last year, we introduced the concept season.
A season is a period of time (usually between 3 and 4 months) where we set a number of features that will have impact to our customers, and our teams.
Before every season, we ask for our customers, and every department of the company what they would like to have as new features and how we could improve their experience.
A season is finished when all game changers features are live.
The “v0”
One key point that helps us to resolve complex problem: We start small, always.
Every time when a major feature which could takes months to implement comes in, we start with the minimum vital (this is our v0), we ship it and we improve it, cycle after cycle, until it reaches what we aimed.
- At first we plan, (scope / perimeter / impact) we use tools such as Tech Study to have a clear overview. What are the problems we are trying to solve? What are the root cause?
- Then we do the crafting part following our Development lifecycle .
- When the feature is done, multiple checks are made, such as metrics measure, performance monitoring, stability, NPS.
- At the end, we act what’s next. How we could improve current implementation? Do we reach what our customers want? What did we learn? How we can make sure that we will not have the same in the future?
This is a part of the PDCA Method.
Reducing wastes
Lean thinking tends to remove wastes. A Waste is any action or step in a process that does not add value to the customer.
In lean there are 8 wastes, but in our case we identified 5 wastes that directly impact us.
Waiting
This is the obvious one, it includes: email/message reply or confirmation, unnecessary or non decision making meetings, code review, waiting for a specific development to begin another one, ability to start a project fast, compilation and deployment.
We could, and this is strongly encouraged to refuse a meeting if there is no agenda, or if you don’t have additional value.
Thanks to Tech study this reduces back and forth during the code review. Code review has to be as small as possible, and should not last more than a day in review.
We bootstrap all projects with custom scripts and containerisation to improve developer efficiency, you clone the project, launch start script, and you can begin to code within a minute.
Overproduction
It occur more often than you think, and it sometimes confused with handle the evolution. It might be tempting to code a feature that you could probably need later or a field in database that you could use in the future, just in case. It seems to be a good idea, but it often leads adding more complexity than it needs.
We are under just in time philosophy, but we always ask what’s next, or what it could be to handle the future easier. When solution seems complex, we go back to the roots: problem solving.
Problem solving > Design > Code > Framework.
Over-processing
Is a glue that slows you down without you even don’t realize. It includes unnecessary steps in the product lifecycle, for example: In every projects redefined DoR and DoD, a Kanban with a lot of unnecessary column. Report, story or task that are too detailed compared to what is needed.
Customer comes before process, always.
Using scrumban, we believe that too rigid process slow down production. This favours Just-in-time and minimising waste.
Most of the content of DoR and DoD are shared across projects.
Tasks are super small.
We don’t need to finish a sprint to release something (spoiler alert, we don’t do sprints) with the help of CI/CD, when a pull request is merged on master branch, the new feature is available on production.
We could have in a single day severals features shipped without compromising stability of the product.
Defects
It occur when product, story or task does not fit the customer expectation or needs, or when it needs to do a rework.
Tech study helps us a lot to reduce this waste. Also, tech team challenges product owner and are a part of product decision making.
Skills
This waste happens when management fails to ensure that people can use all their potential to achieve great stuff. It comes when people don’t have the right tool to do the job, when they are not challenged enough or when the task is below your skill or qualification, when they have poor qualification or insufficient training.
We believe that developers should be included as early as it could on a project, they are not machines that we feed with coffee to produce code.
They can bring interesting new ideas, also, communication is smoother along the project.
We give and ask feedback as much as we can and reward initiatives over compliance.
Before each season, we presents new projects and game changer features and ask to the team what they would like to achieve with a priority order.
Learning as a strategy
Command & Control vs Orient & Support
The traditional approach of Command & Control, is
- Give directions about what to do
- Make sure everything is executed according to the plan
Impact: This, will limit people initiative and experiment, and create misunderstanding about why things are done on a specific way.
e.g. People don’t or barely know what to do, we have to tell them what to do and how.
So we need to setup process / mechanism to know when they don’t stick to the plan, keep them back into the right direction.
Orient & Support
- Show where we’re we are going
- Help people about how they can achieve the goal.
Impact : People are going to participate by themselves in the construction of steps that will make it possible to achieve the objective. It will participate to self-improvement and therefore participate to company improvement.
4F Loop
The traditional approach to build a strategy is 4D (strategy/execution): Define — Decide — Drive — Deal
Define: Top management meet (mostly in offsite) to think about the big stakes of the company.
Decide: They decide a strategy and an action plan.
Drive: They communicate the plan to the teams.
Deal: They manage day-to-day the plan implementation issue.
There is severals problem with this approach:
- The plan never goes as planned.
- People can feel that there is more constraints to their daily tasks.
- Team can feel that their issues are ignored.
The 4F (accept/commit) stand for: Find — Face — Frame — Form
Find: Management goes often to the field to identify the right customer or teams issues.
Face: Facing problems, and communicate the challenges through objectives.
Frame: Translate issues into area of improvements, those are learning, it guides peoples to acquiring the knowledge and skills necessary to solve the problems in question.
Form: Help team to find their own solution, by experimentation (try->see->understand)
Next
We aim to continue to ship as fast as if we were few, without sacrificing quality, even if our teams grows.
Despite we already found kind of a balance, we still continue to improve our workflow.
We are involving more people into our tech study, challenge and initiative are increasingly present.
By avoiding the coding rush to the benefit of “thinking first”, we have reduced our waste, however we still have a lot to experiment and learn.
