Why this document?
When I started Flexiana my goal was to create an environment for senior developers not to do bad engineering ever again.That cultural promise worked to a certain point.
But even really good developers sometimes need challenge and being pushed towards excellence that might initially seem too difficult.
But we're in the business of transferring billions, handling health data, personal information, vital corporate information. Our fault could cost a lot. It's worth doing it right.
This document, even when it is publicly available, is a handbook mainly intended for Flexiana developers. For us, this is not just a proposal. For us, this is a handbook of how things should be done. When the team decides how to do things, the general rules in this handbook are a source of decision-making. And in every moment we have a chance, we nudge the team to adopt 100% of this handbook.
Each team in Flexiana should achieve high level of maturity.
Every time we will get a chance, we will create “a case study” that helps to design and implement this change.
Please, keep in mind that teams can modify all of these things in order to adjust to the situation and what is being done.
At the same time, no team can ignore certain rules just because they don’t consider given thing to be important, they don’t know how to do that, they don’t have a person with given responsibility. Each time is expected to achive 100% compliance with all relevant points and additional steps that go beyond this.
Product management
- Great understanding of users’ needs, personas
- Backlog is well described and maintained
- User Stories are granular so that every developer delivers multiple stories per iteration
- User Stories have acceptance criteria
Long-term maintainability, Code quality
- There is no dead code
- There is no code nobody wants to touch
- There is no untested code
- Refactoring is always allowed
- Testing is always allowed
Starting a new team
- Teams should create first version of methodology that might not be 100% adherent to team maturity
- Teams should vote or choose person who is responsible for adherence
- Team should improve its maturity continuously
Automation
- It is easy to install app (both for development and usage)
- It is easy to upgrade app (both for development and usage)
- Tests are run on developer machines and on integration server frequently (on each PR)
- As soon as the team achieves version 1.0., team releases new version every time anything useful is developed.
- Everything is backed up and we know for sure we can restore any app from backup. We train recovery from backup periodically.
Running team maturity initiative
- Each team owns its methodology. Therefore it is a responsibility of the team to always get better.
- Each point where the team struggles with implementation is escalated.
- Management fully supports achieving high team maturity.
- There are requirements for skills that are not always common in development teams like product ownership, setting up infrastructure. Not knowing something or not being in a role where these things are expected is not a reason not to do any of these.
- Each team has at least one person who keeps track of methodology adherence
Monitoring
- Application and whole infrastructure (servers, databases, cache) are monitored
- In case of error, there is always someone who can act and resolve issue. In ideal case, Flexiana is running 24/7.
- Tests are run on developer machines and on integration server frequently (on each PR)
- As soon as the team achieves version 1.0., team releases new version every time anything useful is developed.
- Everything is backed up and we know for sure we can restore any app from backup. We train recovery from backup periodically.
Developer productivity
- If there is a questionable decision anywhere (product spec., architecture, picked technologies) where change of approach could save a lot of money, the team picks that approach without being told.
- Each developer is capable of delivering multiple stories per week.
- Team members help each other and unblock others. Pair programming and mob programming is supported.
- Every developer deserves code review the same day unless he/she sent it by the end of workday. In such a case, he/she should get review in the morning
- Unproductive team member is supported and helped, but the fact is also escalated to a manager. The same is expected in case of mistracked hours or in case of suspicion of overemployment.
ROI
- If there is a questionable decision anywhere (product spec., architecture, picked technologies) where change of approach could save a lot of money, the team picks that approach without being told.
- Everyone understands that we develop to serve users, not to have fun using technologies we fancy.
- Tasks in backlog either have estimates or are so small, it is easy to estimate how much will it cost to develop them. PO removes stories that are not worth development or asks a team for a different approach that is cheaper.
Join Our Webinar!
Why is it so difficult to move from development to IT management?
Key Topics Covered:
- Challenges: Understand common issues like leadership, communication, and team dynamics.
- Skills: Learn key management skills like planning, people management, and decision-making
- Strategies: Get practical tips to make the transition from development to IT management easier
7 PM
CET
Wed, Nov 27