Bootstrapping development process using Agile principles — TEONITE’S Hints
In today’s blog post we will focus on the process of bootstrapping development process using Agile principles. This is the second part of our series describing various aspects of development process in the context of ”Team as a Service” model.
In layman terms, in general, bootstrapping is a name for a self starting process that is supposed to advance without any external input. In TEONITE’S book, bootstrapping means all necessary elements while starting the project — smaller team, creating internal processes and allowing the team to work independently and become self-sufficient.
Now a word about the idea behind Agile principles. Keep in mind that they can be applied to any product development — it is not a set of rules which are permanently carved in stone to be followed regardless of circumstances. What we would like to do is to briefly characterize each of them.
We have asked three TEONITE’s employees to comment on each of those principles, in order to shed some light on how we tend to approach those in TEONITE.
Kamil — CTO
Andrzej — Head of AI & Machine Learning
Łukasz — Senior Software Developer / Data Scientist
Without any further delay, let’s get straight into talking about TEONITE’S approach to Agile principles.
1. Highest priority is the customer satisfaction
“Client’s satisfaction is our first concern. We are able to direct the customer towards solutions we think are best, but those solutions have to meet all client needs, not ours.”
- Andrzej
“The fact is that the customer’s satisfaction not always coincides with customer expectation. We try to respond to client’s requirements and work according to our knowledge, delivering the solution which the client needed (not always the one he’s asked for).”
- Łukasz
2. Welcome changing requirements
“Even if we think we know what the client wants in the project, requirements can change at any time, due to legal issues or market requirements. It is worth mentioning that we are not in vendor-customer relations (where the responsibility for the purchase is placed on the customer). What we offer is a partnership, where we develop the solution together, and client’s problems are also our problems.
We have to keep in mind that technical requirements are changing. Adjusting to those requirements, constant growth and using latest solutions allows us to shape the client’s awareness regarding what he is able to achieve using most recent technology.”
- Łukasz
“Additionally, we try to make sure that the client is aware that changing requirements during the project results in extended project duration. Also, when requirements change, code refactoring is necessary, so the quality is kept at the highest level.”
- Andrzej
3. Frequent delivery of software
“In order to be able to allow the clients to validate their assumptions, we have to shorten the delivery time of a working prototype (or increment). This way, even if the changes are minor, we are sure that the product we are developing is the product that the client needs. We allow the software iterations speak for themselves.”
- Łukasz
4. Business people & developers cooperating daily
“As the IT specialists we have a broad knowledge of technology and IT solutions. This knowledge alone is not good for much without specialists from different areas. After all, the most innovative products are created at the intersection of many domains, not just one. So if we want to make a difference, we have to work side by side with business specialists.”
- Łukasz
5. Build projects around motivated people
“Adjusting to changing requirements and technologies call for lots of enthusiasm and energy. It is a creative job with lots of experiments and constant learning process. Often it ends up with failure, and we have to solve unsolved problems, which is very time-consuming. Without motivation and willingness this process won’t work. You need people that are motivated and value solutions based on latest technologies. With such employees, there is no need for micromanagement.”
- Łukasz
6. Face-to-face conversation is best
“Nothing works as well as a direct conversations. Obviously the best channel of communication depends on a particular situation and current needs, but in general it works out — the ability to talk face to face is still unbeatable. And we are lucky to be just an hour’s drive away from Berlin — which is crowned as the best startup city in Europe.”
- Kamil
7. Progress measured by working software
“The progress of the project should not be dependent on the length of the project. It is possible that the client will evaluate if a particular increment was a step forward or not. That’s the reason why instead of determining the deadline for the project, we are delivering working solution in the shortest possible cycles, so the work progress can be easily measured and as rapid as possible.”
- Łukasz
8. Sustainable development pace
“We always want to make sure that the teams can establish a repeatable and maintainable speed at which they deliver working software, and repeat it with future releases. This gives the team the stability and confidence making things go smoother. No risk of burnout or other negative consequences related to unsustainable development pace. After all, crunch is what really can impact your employees (not in a good sense).”
- Kamil
9. Continuous attention to technical excellence
“This one is simple. Make sure that anything you do is done as best as possible. Following the latest technologies requires experimenting. When a new library is released to the open source market, we have to use it in the project in order to assess its usability. Sometimes we are able to find a real ‘treasure’ which becomes a must in our technological stack. But there are times when the released library does not meet our expectations entirely and this requires rewriting parts of the code. But in the end, the amount of time we save thanks to implementing new and better solutions is higher than the amount of time we would lose due to poorly chosen libraries.”
- Łukasz
10. Simplicity
“In our book, simplicity is not a requirement. Rather than that, it is a mindset. Very often our clients tend to imagine their product as something humongous, with numerous integrations, data and requirements. Through our analysis and direct conversation with the client we are able to change client’s approach into more ‘incremental’ one. This means introducing hierarchy and listing all features, based on their relevance. Another step is setting down the milestones such as Proof of Concept (PoC) or Minimal Viable Product (MVP). After thinking through or removing some of the less important requirements, and unneeded complexities, it can turn out that we are capable of creating a system which is simpler, cheaper and easier to maintain.”
- Łukasz
11. Self-organizing teams
“This is strongly linked to the trust you have in your team. Give them the autonomy to act on their own accord and do not second guess them. If your team building efforts were successful the team will be able to act quicker and in a more effective way thanks to this approach.
A very common approach is to assume that each team member is responsible solely for their tasks. While it is comfortable from the developer’s point of view, this is not what the client wants. The client could not care less if we are working on one task, or if we have divided it into many smaller tasks — the client is interested in the outcome, which he is able to measure.
Changing the attitude and setting the goal of solving the client’s problem, allows us to create teams which select the adequate work model to the project. We often decide to give up on Product Owners and Product Proxies, because the team has a better understanding of client’s expectations, if they collect and discuss those on their own.
On the other hand, the client will be better informed about the progress of the development and possible difficulties, if he finds out directly from people who are working on the realization of the idea. This cooperation model, based on the team self-determination responsibility brings the project delivery to a whole new level.”
- Łukasz
12. Regular reflection & adaptation
“Everything flows. Technologies change, methodologies change, clients also change. We live in such a fast paced world that solutions aged for 4–5 years are considered mature, most of the big corporations are actively contributing to the OpenSource community, like NVIDIA, Google, Facebook, Spotify and Uber, just to name a few, creating more and more solutions and reaching new heights. To stay on top and develop technologically excellent products, we need to adapt really fast. But, in all this haste, there should also be the time to step out and think whether we’re heading in the right direction and if this pace is the one we want to be in. Without both of those factors, we wouldn’t be in the place we’re in now.”
- Łukasz
All of the above is just our take on the 12 Agile principles. Keep in mind that in the “Team as a Service” model you do not have to worry about proper application of those principles, as each team is agile and seasoned enough to know how things should be done in the project in order to deliver it successfully and within a given time frame.
If you’d like to know our insights regarding TEONITE’S workflow, you can find them HERE
In case you have any questions, doubts or ideas regarding the ‘Team as a Service’ model, feel free to contact us, we will gladly share our thoughts and experiences.
