In this article
Do you happen to hear about custom web applications at every turn? Are there really no other apps in the tank? Let’s find out together what the fuss is all about.
What is not a custom web application?
It might seem we’re taking it backward, but somehow it looks simpler to start this way. So, firstly, let’s rule out two types of non-custom web apps.
Off-the-shelf apps
Off-the-shelf web applications are the ones that you buy as finished, ready-made products. Usually, you can label them with your brand or integrate them with your digital product. But, by and large, you can’t modify them, or it is possible only to a limited extent, not to mention adding new functionalities, that’s way beyond the scope. So, instead, you take the app as it is served.
Ready-made apps are sold to many companies in the same form, often in a subscription-based SaaS model. And it comes with a price.
Customized web app
Yet another type of web application is a customized or customizable app. These products can be personalized according to the client’s needs but usually aren’t built from scratch. Our learning management system Samelane is a good example. It comes as a ready-made package but we also can, and often do, customize it for particular clients, adding dedicated features and functionalities.
When is the off-the-shelf better?
Just to flag it up, sometimes building a custom app would be beating a dead horse. Mainly if you’re working on a low-scale product or app analogous to many others on the market or you have a low budget and prefer to pay a monthly fee rather than spend loads on development. What is more, an off-the-shelf app is ready and can be used in no time.
There are out-of-the-box solutions that can serve your purpose, such as ready-made CRM and CMS systems, e-commerce engines, booking systems, and chats. Hence, it might be more economical to incorporate them into your app instead of developing a new one.
And even when we need a custom app, because the off-the-shelf option demonstrates notable lacks, it’s worth calculating if it won’t be more cost-effective to brush them off. Sometimes adjusting internal processes is more efficient than building a brand new dedicated app. Thus, it would help if you had a custom web application development strategy to decide which option would fit the bill.
The definition of a custom web app
Let us dissect the frog here and assess each of the term components. Then, based on that, you will be able to appraise every digital product.
Custom
It means the product is built according to the unique requirements and business goals, which translate into features, design, user experience, etc.
Web
It means that the product is accessed via the Internet, through a browser. So users don’t have to download, update, and configure it to enjoy all the features,
App
The product provides particular functionalities and two-way interaction, unlike informational websites that present data mainly.
Summing up, a custom web app is a unique digital product that can be accessed via the Internet providing its users with functionalities and allowing for some interaction.
The benefits of building a custom product
Custom web apps are highly desirable when you need:
Unique features
Custom development allows you to craft products like no other. You’re totally free to choose or design its functionalities and UX/UI. Provided, of course, that your unique selling point depends on them.
Scalability
Building a custom product, you’re free to add new features or resources (such as cloud storage) along with your company growth. It is less costly than upgrading the off-the-shelf app licenses. Also, you can integrate your app with other systems in the future, and you’re ready for that.
Independence
An app built from scratch frees you from external providers and the changes they introduce, among others, in pricing. Not only that, but you can also opt out of the on-premise installation, when your security policies prohibit the cloud solutions.
Reusability
If you intend to build the next digital product sooner or later, with at least partially similar functionalities, your backend code will be fully reusable. As a consequence, the development will be faster and more cost-effective.
Similarly to tailored suits, building a custom digital product is more time-consuming and costly (in the short run). But at the same time, it fits your needs better, and the initial cost pays off later.
Custom web application development techniques
It’s time to discuss the stages and methods that lead you from the grand idea to the final product. Same as Rome wasn’t built in a day, a custom web application won’t be either, in fact, there is no such thing as a final product in the case of apps. You most certainly will add functionalities and improve the app with time, based on actual user data. Also, you have to keep tabs on the market and competition activity to keep up and introduce adjustments. There is no time to rest on laurels.
Ideation
First things first, you need a bright product idea. You don’t want to build a run-of-the-mill product, do you? Thus, it has to be an informed decision on how to position yourself in the market. To do so, you will need to:
- Generate the idea: source and develop a clear vision of your product goals and main functionalities.
- Conduct market research: prepare competition analysis and assess their strengths and weaknesses.
- Carry out user research: collect user demographics, needs, and problems your product will solve.
- Map out a business strategy: list a business model, business priorities, short-term and long-term goals, and a plan for how to achieve them. You might feel like a kid in a candy store when it comes to a multitude of possibilities, but you need to keep to your priorities – business strategy is always there to help you.
Planning
So now you know your competition and have a concrete idea of what you want to build. The next step is to put it into action. What you need is a plan that includes:
- Setting milestones
- Thinking of how your MVP should look like and what’s coming next after building the MVP.
- Specifying architecture.
- Deciding on a tech stack: tools, frameworks, and programming languages.
- Defining your web app functionalities and workflows.
- Detailed planning of the next sprints if you work in agile
Design
Now it’s time to work on the visual aspects of your app which translates to UX/UI design. The techniques worth mentioning here are:
- Wireframing
- Prototyping
- Creating mockups
- Branding: fonts, colours, button groups, general look & feel
- User and usability testing
Development
Not to delve into too much detail here; your development team can start working on the app code when the design part is ready. At this stage, it is finally brought to life.
Tests and deploy
Although testing should be done regularly within the development phase, before the product is launched, you should verify if it does the job, as simple as that. Thus, your quality assurance (QA) team has to test the outcome thoroughly in terms of:
- Code quality
- Usability
- Performance, including stress testing
- Security
Remember that the devil is in the detail, so don’t turn a blind eye to any bug! Do not fear, though, because we’ve got an article on tests ready for you.
When it comes to deployment, it’s time to work on the following matters:
- Where the app is hosted.
- How the production, test, and development environment is built
- How installations and updates will work.
- Monitoring and maintenance
- Crash scenarios
And here we go, you’re ready to push the boat out!
Wrap-up
Here’s a quick recap on the topic of custom web apps. They are unique products accessed via the Internet that do more than just inform the users. Particular functionalities of the apps allow for interaction. The custom app’s main benefits are scalability, freedom to develop it as you wish, and the independence they grant you.
However, if building a custom web app gives you the willies, defer to the experts then. We’re always here to help, whatever stage of the app building you’re currently at. We would gladly discuss your project during our free consultations. Just let us know!
]]>In this article
Scrum and Kanban are the most popular frameworks that belong to the same Agile family. Whereas Scrum likes rituals, clear roles and rules, Kanban is more of a free spirit, known for its pretty face (and effectiveness, too!). Which style feels closer to your heart? Which would you like to form close bonds with? If you are on the fence between the two, we’re here to give you a hand.
What is Agile?
Scrum and Kanban are both Agile frameworks, so they share a lot of features. Thus, before we can dig deeper into them one at a time, we need to stop for a while to discuss what Agile really is.
The answer will depend on whom you talk to. Product owners, developers, business analysts, or CEOs might perceive it in a different way. They might refer to Agile as a philosophy, mindset, way of thinking, or, more down to earth, a methodology.
Four Agile values
Agile followers live by four, let’s call them, commandments. Here they are:
- Individuals and interactions over processes and tools, so that you invest more time and effort in face-to-face communication.
- Working software over comprehensive documentation, so that you focus on project deliverables instead of creating lengthy papers.
- Customer collaboration over contract negotiation, so that customer success is your guideline along the way and you’re not blindly following the initial deals.
- Responding to change over following a plan, so that you are ready (and willing) to adjust to whatever happens.
The chief reason why Agile was created and became so popular is that the traditional methodologies, such as Waterfall, deliver value at the end of the project. Taking into consideration that it takes months or years to build digital products, waiting till the end of the way is definitely too long. Therefore, Agile focuses on delivering value faster, in smaller increments. This way you can test solutions, adjust, improve, deliver MVPs, get user feedback, start earning, gain funding, and so on. And on top of that, Agile welcomes changes with open arms, because they typically lead to improvements.
Waterfall approach
Agile is often contrasted with the traditional Waterfall methodology. The latter, linear approach means that you and your team can’t move to the next project phase unless you have completed the tasks from the previous one. It’s also difficult to go back, once something is done.
In Waterfall, you have to identify most of the requirements, analyse them, design, develop, implement a solution, and finally test if it all works. If you proceed step-by-step, you deliver value and get customer feedback really late. The problem is, that if you decide to make some changes, while already being in the last two phases of the project, it will take a lot of time and work. Basically, you need to go back to square one. Another thing, which may happen is that requirements have been understood differently by the client and the contractor/development team. Due to the nature of this linear methodology, you can make this discovery only at the end of the project. Waterfall doesn’t like changes.
Scrum methodology
Scrum is out and away the most popular Agile framework. In fact, when companies say they work in Agile, in most cases they mean Scrum.
Scrum cherishes roles and ceremonies, of which sprints come first: time-boxes wherein other events take place. What makes it highly effective is the/its transparency. All roles, responsibilities, and meetings are clearly defined, and everyone knows what other team members are working on at a given moment. If any disagreement arises, the team discusses the problem and resolves it TOGETHER.
Scrum roles
Roles and their responsibilities in Scrum are clearly defined:
- Product Owner: is responsible for product vision. S/he gets in touch with a client, understands their needs and project challenges. Based on this knowledge, Product Owner creates user stories and identifies priorities for the team.
- Scrum Master: assists the team, helps in their daily work and Scrum ceremonies, and removes project roadblocks. S/he is neither a project manager nor a team member.
- Scrum Team: is responsible for technical aspects and project execution. Everyone that works on the project belongs to this category, which means not only developers but also business analysts or UI designers, etc.
Ceremonies and events
Sprints are the essence of Scrum. A single sprint takes from 1 to 4 weeks. It consists of a variety of Scrum ceremonies and events which include:
- Daily standup meetings. Dailies are the 15-minute meetings that take place every day at the same time and place. At the meeting, every team member answers three questions: what they did yesterday, what they’re going to do today, and if there are any obstacles in fulfilling their tasks.
- Sprint planning meetings. The team thoroughly plans what they can deliver to the client in a given timeframe, that includes not only development but also testing, so the feature is ready to go live.
- Sprint review meetings. These take place at the end of every sprint when the team, product owner, and client discuss the progress and other issues to consider during the next sprint. It’s rather an informal meeting.
- Sprint retrospectives. During retros, the team discusses the last sprint in terms of what they did and didn’t do well, and what should be improved in the future based on lessons learned. The meeting should be treated as a safe space for everyone to share their thoughts, so there’s no room for blaming or criticising anyone.
- Backlog refinement. This meeting resembles workshops. Its aim is to add more details to the backlog once a sprint is underway.
On top of that, there are other terms that you will come across in Scrum: user stories, team velocity, Scrum poker, product backlog, product increment, the definition of ready, and the definition of done. But we won’t delve deeper into the terminology, as we can refer you to some of our more detailed articles in the subject:
Kanban methodology
Kanban is the next, after Scrum, most popular Agile framework. It is known best for its visual aspect, a Kanban board, which helps to understand workflows easily.
Kanban is a continuous process, there are no time-boxes or fixed events. Of course, you can have daily stand-ups and retros but you don’t have to, it depends entirely on you. The key metrics in Kanban are time-based: lead time and cycle time.
Roles and tasks in Kanban
Roles in Kanban aren’t defined, team members comply with their organisational roles. Also, they aren’t assigned the tasks, they simply pick the cards from the board depending on their skills, talents, or what they feel like doing at the moment.
In Kanban, there’s much room for companies and teams to lay down their own rules and policies on how to manage things. The key is to make the policies explicit and known to everyone concerned.
Kanban board
The project board shows the status of work in progress, so one look at it should give you an idea of how everything is going. Kanban cards contain information on tasks and they are grouped into three areas: to do, doing, and done. Usually, their hierarchy is set from top to bottom, beginning with the highest priority. Team members pick their tasks and as time goes by, they move them between three sections of the board.
Kanban boards can be physical, arranged with sticky notes, but online ones have become more popular. The reason for digital Kanban boards preference is the hybrid and remote work, requiring the dispersed teams to collaborate closely. Online Kanban boards can be created with a variety of well-known apps, such as Trello, Jira, or YouTrack (Agile Boards function), which we use in NeuroSYS.
WIP limits
Kanban concentrates on task completion. Too many tasks marked as in progress might indicate that the work is not proceeding or the tasks were put on hold. That is why Kanban limits the WIP, work in progress. A good practice to keep focus and get things done is to set WIP limits in your online Kanban board.
What is the difference between Scrum and Kanban?
Being Agile frameworks, Scrum and Kanban have a lot in common, such as task estimation and focus on delivering value in no time. But now it’s time to get your arms around their disparity.
The difference between Scrum and Kanban lies in a variety of aspects, more or less fundamental:
- Structure: Scrum is highly structured. All roles and meetings, including their duration, are clearly defined. Kanban is fluid and way less structured. There are no set roles, sprints, and meetings (if you don’t need them).
- Time-boxes: In Scrum, your work is divided into 1-4-week sprints. That’s the essence of the framework. With Kanban, the work cycles are fluid, you move from the to do tasks to the done section without clear breaks.
- Retrospectives: In Scrum, the discussion on what worked, what didn’t, and why, takes place after every sprint and constitutes its inherent part. In Kanban, you organise a meeting whenever you feel it would be good to talk things through.
- Tasks: Scrum tasks are assigned to the specific team members. In Kanban, it is team members that pick tasks for themselves and take ownership of the assignements.
- Roles: In Scrum, you’ll find team members with set roles. In Kanban there are no specific roles defined. Team members comply with their organisational roles.
- Teams: Scrum teams are cross-functional, they have all the competencies needed to carry out their tasks. In contrast, Kanban teams can be specialised, such as teams of testers or engineers.
- Metrics: The key metric in Scrum is velocity. It reflects the number of story points that are delivered in each sprint. In Kanban, the key metric is cycle time, which is the time that passes between the beginning of the task and its completion.
| AREA | SCRUM | KANBAN |
| Structure | Structured | Less structured |
| Time-boxes | Sprints | Fluid cycles, no set breaks |
| Retrospectives | After every sprint | When it makes sense |
| Tasks | Assigned to the team | Picked by the team |
| Roles | Specified | Non-specified |
| Teams | Cross-functional | Cross-functional or Specialised |
| Metrics | Velocity | Cycle time |
Is Kanban better than Scrum?
And is an apple better than a pear? This is a similar type of question.
Or, as our Managing Director would answer, IT DEPENDS. It depends on your organisation, team composition and its members’ experience. Naturally, personal preferences play an important role as well.
The fact is that organisations which have already started their Agile journey, in most cases have begun with Scrum. The framework offers structure and a set of rules that are helpful, especially at the beginning. Starting straight away with Kanban might feel more like throwing yourself in at the deep end. But it doesn’t have to be this way. Kanban can be a made-to-measure approach, particularly when increment of work isn’t linear and the project has to pick up speed first, before it will be monitored and managed.
Generally, if matters like cyclical delivery of increments, tools for work planning, customer engagement, transparency, and retrospectives are important to you, you should go for Scrum. Meanwhile, Kanban works perfectly during maintenance periods when the system goes through end-to-end tests or is streamlined, or technical debt is being paid off. In situations where work is hard to plan, Kanban is a perfect match.
To give you food for thought, Kanban doesn’t have built-in retrospective mechanisms. Thus sometimes it is difficult to give a sense of purpose and success, to the team and clients. Scrum secures that thanks to cyclical events and clear sprint goals.
For those who are still undecided or like both options equally, there is something in between, a framework called Scrumban. It is a blend of Scrum and Kanban, taking the best practices out of each. For example, in Scrumban you use the Kanban board but also have mandatory daily meetings.
As you can see, it isn’t a black-and-white choice to make. We can’t categorise the projects as Scrum- and Kanban-prone just that easily. What we can suggest here, is to use Scrum/Kanban as logic dictates, taking into account the above-mentioned benefits but also limitations.
Scrum vs Kanban wrap-up
We can’t praise Agile methodology enough. No matter whether you choose Scrum or Kanban, Agile’s focus will be put on software quality, effectiveness, constant improvement, great results, and trust in people. Simple as that but most importantly working.
Bob’s your uncle, we’ve reached our destination. But what a journey it was, right? At the end of the day, the choice of the framework is yours, though we hope we’ve managed to help you out. If you’re still in two minds about it, let us know. We can give you a helping hand during free consultations.
]]>There’s another breakdown, as those who do, divide further into
- those who test backups
- those who apparently do not have backups
As for the second group, it all depends on assumptions and the choice of tools in use. What may have appeared a good idea to store data, can be easily exposed as insufficient in case a security breach occurs. Preserving resources from intrusions, equipment failures, and catastrophes is crucial to preventing data loss events.
How to prepare data for restoring once something goes wrong?
In the perfect world – a 3-2-1 backup
The 3-2-1 is a desirable, yet difficult to achieve approach, where data is thoroughly secured by various means.
The perfect setup
What storage types do we mean by various means?
- another drive in the computer
- an external USB drive
- an external drive in a different PC
- cloud drive
- a pen drive/CD/DD
- any other data carrier/storage device (e.g. tape drives used mostly by corporate entities, like AWS and their Glacier service)
Where can the backup storage be located?
- the same device (not great)
- the same building (ok, but could be better)
- another building (better)
- another country (in the case of servers and cloud. Good, but not ideal*)
- a portable, handheld device (could be great in case of an on-site accident, yet still unfavorable when lost or stolen)
*not ideal, as reminded by an extensive fire at the OVH location in France, which downed millions of websites in May 2021.
Storage is not the end of the story
Protecting data from malicious actions and other unfortunate events doesn’t end with keeping it out of the hands of unauthorized users.
Further steps entail:
- encrypting
- encrypting
- And just a little more, just to be sure – encrypting
(which applies to private, professional, business data of critical meaning and isn’t necessary in case of storing backup copies of e.g. legally purchased music, movies, games, etc.)
How to encrypt?
Full Disk Encryption
As the name suggests, it applies to encrypting whole discs. Covering with care the whole asset is the easiest way to protect the data it carries.
Windows
BitLocker – built-in
VeraCrypt
macOS
FileVault2
Linux
VeraCrypt
Dm-crypt (LUKS)
Selected files or catalogs
7-zip – a file archiver with a high compression ratio
Cryptomator – great for encrypting files in the cloud
GnuPG – recommended for encrypting communication
Cloud data storage
Maximum security thanks to end-to-end encryption
MEGA
Filen
While we vouch for the above solutions, when it comes to critical data, we still recommend further security measures. Tools like Restic and BorgBackup support backup and deduplication, which helps manage stored data. Backup Ninja and UrBackup help achieve not only safety, but also fast restoration time, easy restoration, and management of automated database backups.
How do we backup our code?
We use an AWS S3 bucket to store data, followed by at least 2 copies of each 2 recent backups stored on our infrastructure. Both the infrastructure and bucket resources are backuped daily. Once a month, we transfer the recent backup of the most critical assets including GitLab, Youtrack, Mattermost, and Bitwarden to an external drive.
The AWS S3 provides an object lock mechanism, which secures from deleting or overwriting stored backups.
The lock has two retention modes:
- Governance mode – users can alter resources if granted special permissions
- Compliance mode – a 100% protection from tampering with the stored data, securing it even from the root user of the AWS account
The tool requires setting retention periods during which set objects remain locked and under WORM protection. WORM stands for Write Once, Read Many, and is an element of storage where not changing stored data is critical.
Another useful mechanism provided by AWS is Bucket Versioning, allowing users to store multiple versions of a backuped resource in the bucket. As a result, each attempt to overwrite the backup results in creating (and storing) another version of such an item.
AWS S3 – storage class
Amazon S3 Standard-Infrequent Access
A standard way of storing data, paid by per set time period, irrespective of how long in fact data is preserved on AWS servers
Amazon S3 Glacier Deep Archive
A file archive with smaller costs, but with a minor inconvenience, as access to stored resources requires time (12 hours from request to access to desired backups)
AWS backups are automated using a file lifecycle
Once a day we upload a daily backup of every tool we use. This data is available right away for 30 days and after this period, it is labeled Expired and lands in the queue for deleting.
Every week we upload a collective backup to the Glacier Deep Archive. After 180 days, these copies are labeled Expired and deleted.
Each backup is marked with a relevant tag (Daily, Weekly) for easier management and is secured by an object log protecting it from deleting and overwriting.
Backup tests
Every 2-3 months, we test our safely stashed resources. Using a separate server and the Docker service we make sure our backups are valid and ready to restore data in case of necessity.
This step should give the final answer to the “do we really have backups” question.
Coming back to the initial question – to backup or not to backup?
There’s no other good answer than yes, you should backup. Securing data critical to executed operations is necessary to maintain continuity and avoid operational downtimes. Better safe than sorry, no matter how cliche it sounds.
Recovering from unplanned events is critical to maintaining operations, and as such, shouldn’t be overlooked in favor of seemingly easier, inconsiderate approaches. While backups may not seem to be the most exciting part of software development, their importance is impossible to overestimate.
]]>In this article
Overemployment refers to professionals juggling two – or more – jobs, usually full-time. While balancing a regular 9-to-5 position with some minor gigs is nothing unusual, especially in the creative area, combining two regular jobs is something relatively new.
The problem hit the wider public conscience after the pandemic started, sending hundreds of thousands of employees to work from home. The increasing problem was noticed mostly among companies hiring IT professionals, who, working remotely, started cooperating with more than one entity full-time.
But how is this even possible? The IT industry is very specific when it comes to the relation between active work time and final results. Unlike, for example, the carpentry where hacking, sawing, and splitting wood takes always a certain time for predictable, repeatable results. Or cooking – setting 3 ovens simultaneously won’t make the turkey ready in 3 times shorter time, and no other hack will significantly cut the processing time. What we’re saying is that there are expected time ranges for specific activities (which we use while estimating projects). However, developers sometimes lose sleep over a missed comma in the code, while on the other hand, sometimes solving complex problems requires relatively little input.
And this is where the problem in question arises. Developers, working remotely, can save up spare time that they don’t spend on watching movies or playing table football. Instead, they find another full-time job. No one would ever notice, since all work is carried out remotely, right?
What are the risks of overemployment?
Companies strive to avoid overemployment due to emerging threats to their operations:
Efficiency decrease
On the employee side, balancing double the workload (especially when there are more demanding, time-consuming tasks) can easily lead to burnout, excessive stress, and fatigue.
Rising costs
A full-time employee that doesn’t deliver the agreed and expected results can be a threat to project outcomes, endangering companies’ interests.
Image risks
Companies that struggle to complete assigned work incur damage to their reputation.
Further destabilization
If one employee gets away with permanent overemployment, why wouldn’t the other team members eventually try to do the same? Consenting to such behavior can cause an avalanche of further inefficiency in daily operations.
Financial loss
Overemployment is an indirect loss for the company. Knowing that employees can be so resourceful and efficient, the team could have twice the work done within the time the developer is paid for.
How to recognize overemployment?
The clues are noticeable, however, they don’t always necessarily need to indicate employees working 2 (or more!) full-time jobs. Companies that established and put to good use their processes are less likely to suffer from overemployment. During sprint planning, work is divided between team members who take responsibility for delivering estimated results. After each sprint, the outcome is assessed. The teams’ objective is achievable through joint efforts, and a one-time or occasional mis-delivery can be forgiven, just like a sporadic unrealistic estimation, but it’s a major red flag once it becomes a tendency.
Commitment
Sure thing, a job contract, even a full-time, permanent one, isn’t the same kind of obligation as e.g. marriage. Employees don’t marry their bosses or teammates (well, at least not as a general rule, and who are we to judge). That doesn’t mean that the mutual relationship doesn’t entail some commitment. It’s also about being fair to each other and avoiding cheating. When the dedication to performed tasks decreases, the reason behind it should be identified. The problems may be temporary and caused by some external factors, but a prolonged disruption to work efficiency is alarming.
Timelines
Coming late to every team meeting? Always leaving the daily meetup earlier? Oftentimes troubles with adjusting to the company’s daily schedule may indicate regular obligations elsewhere.
Excuses
Sometimes, everyone encounters obstacles in their work. Usually, the problems are solved right away by cooperation within the team. Continued disruptions caused by minor technical issues that are easy to fix can show the approach of the employee in question. For example, a team member regularly reporting troubles with completing a task doesn’t specify what the issue is resulting from. After a brief inquiry, it appears that the developer lacked access to a critical resource without which the work couldn’t be completed. Instead of notifying the project manager and requesting access, the employee continued to hide behind the problem and slacked in their work. In other cases, the smarty pants individual reports problems just for the sake of doing so but doesn’t seek help with resolving the issue. Or even rejects offered help from teammates and PMs.
What we’re saying is that some above occurrences may happen due to other causes. Let’s say, the team always meets for the daily stand first thing in the morning, at some un-divine time like 8.00 AM. The developer in question is rather the night owl type or works from a different time zone. There’s no wonder they usually come in late and seem rather absent. Or the start of an afternoon meeting collides with the time their kids come back from school and require attention right here and now before the parent can go back to work. Our team members have their lives and quirks, and as long as there’s mutual understanding and these factors do not interfere with work (or can be counteracted, to an extent), we’re good.
How to prevent overemployment?
It’s a… you’ve guessed right! A process.
More precisely, in this case, it’s about how we work. Choosing the right candidates when building the team, estimating and scheduling in a rational manner, assuring motivation and mutual honesty. This may not be a bulletproof, 100% sure recipe for success, but that’s the best companies can do to proof their operations against smooth operators. When the team is tight-knit and dedicated to achieving common goals, the individual posing a threat to the objective and working two jobs on the sly will be quickly noticed.
We’re not saying that project managers need to keep notes on their team members’ preferred bedtimes, but, to an extent, knowing your team and their small quirks (like choosing to do some work at night for not getting up with the first rays of the sun), along with their time zones, leads to a better understanding of the teams’ performance.
Ensure understanding
Cooperation requires understanding. Despite times of fully remote work, modern tools allow effective communication, collaboration, and exchanging information. Project managers gather feedback from their teams, and when certain attitudes among team members are considered unacceptable in the long run, further steps can be taken.
Don’t micromanage
While we’re all for transparency, which oftentimes requires some kind of task tracking and supervision to ensure smooth workflow, we shudder at the thought of micromanagement. Avoiding it, especially in times of fully remote work, sounds easier than it could actually be, but that’s again when the process steps in. “The eye of the master will do more work than both his hands”, as the saying attributed to Benjamin Franklin goes. In cases when there’s compelling circumstantial evidence an employee is playing both sides, paying particular attention to someone’s work is necessary. The clues being as above, a developer hanging around, working half-heartedly, and at the same time, denying it with strong force. That’s when micromanagement may be required.
As we mentioned in the beginning, there’s nothing wrong with full-time employees that like to do some extra side jobs, as long as their additional gigs don’t interfere with their core duties. What’s also important is the good practice of not engaging with the direct competition of the primary company (what is the common case in overemployment). We’re however highly convinced that agreeing to a position that entails full commitment in the traditional hour range should be associated with being fair with the company.
As a matter of fact, engaging in another full-time job and working half-heartedly (there’s another phrase for that that we’d like to use but it might be a little too much, let’s just hope you know what we mean) is not better than just slacking off during working hours by spending days on social media, playing video games, or watching movies. Such an attitude is a calculated risk of remote work and a growing problem in the industry, that we’re prepared to address.
Our team is as remote as they wish to and hard-working, so if you’re looking for a digital partner to make your product bloom, let us know. If you’d like to talk about what we can do for you, book your one-hour free consultation, and let’s see where it takes us.
]]>Health checks – where to check the pulse
A few words of introduction on the process. Since health checks are most commonly executed on the backend, this is what we’ll focus on.
Each backend-side application needs to communicate with an array of external resources in order to properly process incoming requests. The resources in question include everything apart from the application itself – a database to query on, a rest API to call to, a queue to push an item into, etc. Even if the application in question works locally, it uses a drive to serve and save data, making the hard drive an external resource as well.
Without these resources being fully operational and accessible*, the application can’t perform properly. Depending on the scenario, it’s an unambiguous answer from the service that might signal the handicap. In other cases, the buffer between an error occurring and the error-causing app malfunction may last considerably longer – up to several days or even weeks, during which the issue remains unrecognized.
*Accessible and operational resource – what does it mean exactly? In the discussed context, the health check doesn’t end after assessing whether the resource is present, visible, and accessible. The check verifies whether the resource is capable of performing actions required by the application (as in suiting its needs).
For example, a database health check will also execute a simple, casual, query like “SELECT 1”. Such a step ensures the database can process queries and the application is authorized to execute them. As a result, the risks of app disruptions are reduced to an extent.
In short, it’s not the resource existence that is verified – health check updates the status of granted access, authorization for saving data, and others, according to the needs.
Liveness and readiness
Without diverging (at least this time) into topics like Kubernetes, containers, and other in-depth matters, we’ll just mention that during checks, we assess the architecture’s liveness and readiness.
As the concepts aren’t synonyms, a check signaling the resource to be alive but not responding in a short time may indicate its malfunction too hastily. The case may be that the said resource is working properly, but its readiness requires more time (as long, of course, as it fits set benchmarks for the architecture in question).
Why do you need software health checks?
There’s no complicated explanation needed. Software architecture needs to be monitorable – allowing for the ongoing supervision of its condition. By ongoing, we don’t mean a dedicated admin, a site reliability engineer, or a DevOps professional to be assigned to constantly check the health of a service 8 hours a day, 365 days a year. Clearly, there is a lot of space for automation here, but the process itself always starts with some kind of indicator, triggering further actions.
Health checks can serve as such agents since they indicate the general state of the microservices and their dependencies.
Having health checks exposed, the dedicated monitoring software can periodically check on them. As a result, the engineering team has information about the solutions’ architecture elements experiencing downtimes or malfunctions. This should be subject to automated reactions.
What reactions can it spark?
For example, a load balancer redirecting traffic to another service, a container orchestrator attempting to restart the unresponsive database, or even sending emails to the people responsible for certain processes can’t be easily and automatically diagnosed and recovered.
How often should you check the software’s health?
The most intuitive answer would be: often and regularly. But that’s a rather vague response. Regular could mean every single minute, every 15 minutes, or even once a day. It depends entirely on the use case, the application’s expected availability, and the risk at stake. Health checks by default shouldn’t be expensive operations, but sometimes, in more complex scenarios they might be (e.g. if the health checks are performed in the cascade form on the app dependencies) and the amplitude should be adjusted.
Again, in short – as often as possible, but without exaggeration.
Cascade checks
One could say that the health status of the examined service relies on the health status of all its dependencies (as we somewhat stated a few sentences above). Assuming this is the case in the given application, it might be a good idea to implement health checks that happen in a cascade way, so the external resource is verified by calling its own health check. Calling health checks on the roots of the architecture graph will give the information about the overall health.
Are health checks vital to software development and management?
We don’t mean to sound overly dramatic, but assuring the application works properly is one of the keys to delivering stable and safe services to end-users.
What we’re saying is that health checks are not a whim, but a necessity. Maintaining functional, efficient, and safe software cannot do without constant monitoring of the builds’ health. Software developers need to assure that all resources are available, the authorizations are up-to-date, and data saving is possible. As we’ve elaborated above, this reduces the chance of app disruptions to an extent.
Software health checks aren’t the only area to oversee in the development process. Are you looking for a digital transformation partner to take care of your software project? Book your free one-hour consultation to find the answers to all your questions regarding the process.
]]>Some companies tend to overuse the phrase, but we know one thing for sure – software development (on a business level) is a team sport. In this article, we’ll share a part of our experience in recruiting, building, and maintaining software teams that deliver.
How to form efficient development teams?
First of all, what is a developer team?
This one’s easy. A group of developers, often supported by other specialists, working together on software projects. No matter if in-house or outsourced, the group cooperates closely to deliver achieved results.
Roles to be found in development teams include positions such as
Does an efficient developer team need all of the above roles to function and deliver? Absolutely not! Or rather – it depends. Teams are formed according to the needs, previously recognized and addressed. The situation looks different when providing outsourced teams to clients who already have their own in-house teams that need support in coding, different in case of building products from scratch for clients with no technical expertise aboard, and can result in a changed team structure anytime a different situation arises. As you can easily guess at this point – a team’s composition may change over time, not only resulting from employee rotation but from shifts in priorities and ending work in certain areas.
Our developers carry out tasks in various compositions, both as a support to IT departments on our client’s side and as complete development teams building whole projects, taking care of each aspect on the way.
Who to look for when rounding up the team?
Everyone’s invited. Especially when it comes to the professional background. The IT field is unique in this matter, as people with academic backgrounds, course graduates, and self-taught individuals can work equally well (however some differences are noticeable, but more in the general approach to software architecture). Different personalities cooperate within diverse teams, and since we value results over strict procedures, there’s space for both, extraverts, introverts, and everyone in-between.
Who to omit when building the next best developer team?
The lone wolf tech geniuses
While we’re all for working with other bright minds, we’re aware of the possible challenges of hiring geniuses in their field of expertise who struggle with teamwork. Not once and not twice did software development companies face unfavorable situations where the highly skilled but difficult in cooperation individuals walked away from projects, leaving teams with the challenge of maintaining their code. Termination of cooperation in such cases causes difficulties, as the decision itself is not easy, and communicating it to the person concerned may spark diverse reactions, some of them difficult to deal with.
The unfeedbackable individuals
We always assume people mean well. Sometimes errors or misunderstandings occur, and in such moments, we do what we can to help solve the problem. This requires feedback from peers and managers, followed by the anticipation that efforts will be made to bring things back on track. Individuals who continuously struggle with accepting received suggestions may not be promising in further cooperation.
The budget crashers
Money is important, and we all work not just for job satisfaction (as it’s darn hard to use it to pay our bills). However, the salary levels for each position are more or less finite. As a rule of thumb, in the IT field, when reaching a certain level of remuneration, employees are more motivated by what the job offers on the challenge side, allowing them to grow professionally. What we mean to say is that there will always be a company willing to pay more, but not necessarily offering more when it comes to personal development. Having this in mind, we offer satisfactory compensation, but aim to attract and retain professionals with the work we do.
Diversify the expertise level
Building teams with juniors only is a rather hazardous decision. In such cases, developers working with peers on the same expertise level won’t be able to grow in their field as no one will be able to provide them with the right feedback. Junior teams may grow technical debt in an uncontrolled manner (meaning the loan is taken without resources having sufficient skills to pay it in a managed way), and working with solely entry-level developers can be compared to building a house on a less robust foundation. We’d say it’s better to invest the most in concrete foundations, and consider the less-experienced staff to work on parts of the build (painting, carpentry, arranging tiles) that won’t cause safety hazards. Or allow juniors to cooperate with mids and seniors on the core elements, instead of approaching them on their own. Diverse, self-organizing, and well-equipped teams can achieve the desired synergy, allowing for the best results.
Additionally, we strongly disagree with a popular saying that “any specialist can be replaced with a finite number of students (or interns)”. It’s a peculiar approach, short-sighted to say the least, and highly probable to endanger the carried-out projects. Instead, we’re on the lookout for promising interns, who will join our team. Each year we hold summer internships with the hope of hiring the most talented people, later on, allocated with more experienced employees to continue learning.
How to properly assign tasks to people (and people to tasks)?
Delegating tasks can be a headache for managers, but knowing their team, their potential, and their capacities is the key to matching the right people with the incoming tasks. While allocating new hires to particular projects we make every effort to place developers where their skills will shine. Additionally, the workload should constitute a challenge to team members, triggering growth. Sure, our clients’ needs are the priority, and sometimes dull tasks need to be carried out, but we remember about the developers’ needs.
More mentoring, less supervision
Is there anyone enjoying micromanagement? (Perhaps except for overeager junior managers). Most developers prefer working independently, as much as possible. With great power comes great responsibility, and the people who can handle it with care are the best that can happen to a team. That’s why we trust our teams and refrain from micromanaging. Instead, we allow making mistakes, as long as they bring reflection and analysis for further improvement.
What’s the recipe for a successful development team?
Understand the needs
What to do when things go amiss?
Even in the most friendly environment with the best practices, something may go wrong while building a team or during further cooperation. Challenges may result from internal or external factors, but no matter their origin, the results could affect achieving objectives and as such, need to be taken care of. The sooner, the better for both the team and the project. The key to tackling emerging challenges is, as mentioned above, feedback. Most issues in projects are caused by processes, not by people. We make every effort to discuss possible solutions and strategies for implementation. Learning from every situation, we adapt to future scenarios.
Once again, how to build development teams?
This is how we roll.
Our HR department is always on the lookout for new highly skilled software developers to join the team. The needs – as we previously mentioned – vary depending on the seasons (as in workload, clients’ demand, shorter deadlines in high-priority projects, etc.). This means that sometimes we focus on acquiring more specialists proficient in certain areas. Sometimes we’re just casually searching for more tech bright minds to welcome aboard, knowing that new extensive projects are just round the corner.
Since we value our candidates’ time, our recruitment process is short and substantial. It can be boiled down to 2 steps:
The tech check: The tech interview, where we assess hard skills and their compliance with offered positions
We look for skills and disposition. Depending on current needs, we may be open to hiring individuals with slightly lower tech expertise in cases where the attitude and general impression convince us the person will be the right fit for the team. For the team in general, as during recruitment, we sometimes don’t know yet which project, in particular, will the new hire join.
The takeaway
There’s no one absolute truth in building developer teams. Various strategies can work equally well in different conditions.
We aim to acquire the best professionals who can cooperate efficiently within teams, delivering the desired results. On our side of the process, we strive to offer the maximum possible space for development, but aim to keep it real. No empty promises, both to our clients and our developers. We’re realists, there will be some less challenging tasks, and maybe even some meetings that could have been an email. But in the long run, it will all be worth it.
Do you look for a team of bright minds to carry out your software development project?
Book your one-hour free consultation and see what we can do for you.
]]>Sometimes, and in the case of aged, voluminous projects rather sooner than later, comes the time to decide on flipping the build upside down.
The dreaded CODE REWRITE.
Maybe you share with us the same memory from primary school. Once you got fed up with a poorly filled notebook, you decided to start all over again. The story ended each time the same – purchasing a new notebook, meticulous copying of previous topics onto new, unspoiled pages, often adding colorful annotations and other bells and whistles. Rewriting continued, but most often before you finished transferring all previous topics to the new, better notebook, something went wrong, and you either stayed stuck to the old one, full of scribbles and chaotic notes, or continued until the end of the term with two notebooks, none of them doing its job properly.
So that’s for our long-hidden memories of rewriting things. Years have passed, and here we are, talking about rewriting way more serious things than your 4th-grade biology notebooks.
We’ll start from here with something you might already know from our works, the process.
So, how to know it’s the right time for rewriting your build?
The above quote should apply to the considered technology rewriting. When done at the wrong time, it can have catastrophic consequences.
Too soon
Starting the rebuilding process too early can result in generating unnecessary costs. Proper business analysis should prevent us from taking such vital measures in case something may change in the distant future, while there’s no clear indication it’ll happen for sure.
Too late
As a software development company, we’ve come across examples of companies that haven’t decided to rebuild their structure when it still worked well. What they didn’t know was that their structures needed time to be rebuilt – and when the shift ended, it was too late to maintain operations. Should they make the decision earlier, the new infrastructure could be completed before the old build lost its capabilities to handle incoming traffic.
Before diving head-first into revolutions in your digital product, a proper health check of what lies underneath is necessary.
What to look for while doing the health check?
Assessment of infrastructure’s shelf-life should include the following matters:
Performance (scaling limitations due to architecture, outdated technology)
Your business is meant to earn and, most often, grow. What if the architecture that was fine at the beginning of your path has reached its limits? Moreover, since code rewrite requires time and the product is flourishing and gaining new users, will the structure withstand the expected workload e.g. a year from the point the need for changes is recognized?
Don’t let the inability to scale restrain the business from reaching new heights – make sure the technology you use is ready to handle greater traffic and workload. The same works for integration with new or upgraded external systems, which could potentially cause issues with the present structure.
Up-to-date manufacturer support for specific system components or user-side technologies (e.g. Adobe Flash Player)
You may be used to the technology of choice because it offered the best value at the time you incorporated it into created projects. Nothing lasts forever, unfortunately, and some solutions just fade to grey. This happens even to widely used and appraised tools, like the famous example of the popular Flash player ending up unsupported by the end of 2020.
Security requirements (security audits)
In this section, we wanted to use the analogy to actual weapons, but we feel that in March 2022, said comparisons aren’t fit for the business content. Back to the point – the security of your architecture is one of the most important matters, and as such, requires solutions good not just for now. Companies often face app safety challenges caused by security gaps in components used in the current structure which aren’t developed further. Instead of sweeping threats under the rug, the sooner the issues are addressed, the better for the build.
Choose wisely among reliable options with both, a good history and a good outlook for the future, to ensure the best protection against possible threats.
The ability (or necessity!) to move to the cloud
The cloud is a powerful ally in building robust software products and as such, helps with scaling according to the needs. Regrettably, not every business can or wants to move their build to virtual machines. In the case of e.g. a merger with another entity, assessment of whether the technology allows transition to virtual servers is necessary. Some companies want to move to the cloud due to economies of scale and workload (not wanting to maintain infrastructure left unused outside of peak times), but what separates the need from actual transition is the process of adjusting the architecture. Identifying challenges regarding the move and approaching them properly calls for in-depth analysis.
Strategic and corporate decisions
Business decisions affect companies on multiple levels and strategic shifts (mergers, acquisitions, partnerships requiring particular technology used by other parties, etc.) have side effects. As a result, rewriting the whole structure or some parts of it may be necessary to achieve compliance among used software to continue with delivering assumed goals.
Availability of experts in a given technology
In some cases, the search for the last remaining developers in languages your architecture consists of may not be worth the struggle. Let the 3 reminding Haskell developers carry on with their peaceful lives and consider rebuilding the system with technology that’s backed with an extensive, blooming community.
What else needs to be taken into account when considering rewriting code?
Time and costs
How long will it take and how much money do you need to secure for rewriting your architecture? In short – it depends. Whether the whole system will be rewritten or just chosen parts, the process can vary in length, complexity, and, what follows, costs. Code rewriting should be done in a set, finite time and estimations should take into account possible scenarios.
The challenges in estimating code rewriting boil down to the emergence of new ideas. Who wouldn’t want to include an array of new features, since the old package is already under construction?
Planning
So, you have a team that rewrites parts of the architecture for the better. But is there anyone still maintaining the old parts? You have a working product, used by thousands of people. The worst that could happen is affecting the way the product behaves, causing user outflow. Maintaining the working parts while others are rewritten can be costly, but losing clients is more expensive. Should the enterprise freeze their product and leave an “UNDER CONSTRUCTION” banner greeting users? This could – and often will – result in customer outflow. Most probably rewriting parts of the structure while others work unaffected will be the most beneficial strategy.
Data
A working product contains gathered data, which most probably needs to be transferred to the new structure. The migration may be a challenge in itself, as old data may need adjustments to be still useful in new conditions. Complicated migrations resulting from new architecture sometimes make companies wish they could abandon old data sets and start over again on the new structure (which is possible in some cases but can’t be considered a rule).
Old, but new
What will the architecture be after the rebuild is complete? Does it change only on the backend side (integrations, security, etc.) or will the functionalities differ, which also could discourage users? Take time to decide whether new additions are necessary to avoid overdoing.
One of our clients needed rewriting their old and complicated software to work properly in web browsers. We started with creating a new frontend, preparing the API to match the existing build. As a result, the client gains a working browser version, and we can focus on replacing backend elements, without disrupting the product’s functioning.
Communication
Sure, some inconveniences may occur and affect the users. Prepare ahead for such possibilities, ensuring the most transparent communication, reaching the clients before application downtimes will.
And one thing to avoid: hype
New technologies and other shiny bells and whistles need to stabilize and consolidate a little before you’ll trust them with your life’s work. We highly recommend focusing on in-depth analysis and business insights, instead of diving head-first into hype-driven processes.
The world changes. And so does technology
In a world where we’re all used to certain technologies surrounding us all the time, like the omnipresent JavaScript, Python, C#, we may forget – or not even be aware of – the great old ones, nearly ancient languages who were there when it was written. Being an archeologist seemed great when we were kids but dealing with old-timey programming languages poses problems. Usually having to unearth something nearly forgotten is a challenge to the company. Like COBOL, known since 1959, still used by some developers, who for some reason won’t be replaced by their successors.
If not rewriting then what?
As we already said before, rewriting the architecture is not just about the technology. The business models and needs vary, and there’s no one-size-fits-all solution. Turning the build upside down, however often necessary, may not be the right step for the company at any given time.
Maintaining the existing structure can be facilitated by refactoring, restructuring the code to handle the technical debt building up in the meantime. In some cases, refactoring your code can be sufficient to achieve desired results, and continue with successful operations. Tread carefully, as no solution is once and forever – instead, keep a watchful eye on your software, the way it behaves, and how the drivers change to be ready to act in time.
Is the time now?
If you have a growing feeling your architecture might require rewriting, but don’t know how to approach the change, book your 1-hour free consultation.
Approaching code rewrite requires a strategy, ensuring the process will affect your operations as little as possible. Our analysts and architects are here to help you assess the challenges and opportunities, making every effort to execute the process in the most beneficial way for you and your business.
]]>As it isn’t a run-of-the-mill solution, not all companies might have it on offer. Still way more common are free consultations, which by all means are a great way to verify your potential contractors at the initial stage and remove those not suitable from your list. But interviews won’t show you how the cooperation would get along in practice.
What is a software development trial?
In short, it is one of the most effectual methods of verifying your future software provider before you engage in long-term cooperation. During the trial period, they work on your product, usually a single but a fully functional solution, so you gain insight into their effectiveness and software quality.
This approach aims at minimizing risk for both sides – for you, dear client, and for us, software providers (more on that in The major benefits section). All because digital product building is a mutual process that largely depends on effective cooperation. The product built is a result of both sides’ input and heart for the project.
The steps of software development company verification
Now, let’s place the software development trial in the process of looking for the most suitable contractor:
- An initial check. You’re rooting around companies on the market, searching Google, checking development company rankings, reviews, technologies they excel at, and scanning the firm and its team (among others case studies, clients, and LinkedIn profiles).
- Interviews/consultations. Of course, you don’t want to put all your eggs in one basket. Thus, you prepare a list of companies that you want to talk with. Don’t forget to ask them these 8 questions!
- Software development trial. Ideally, after a round of interviews, you feel who’d be the best fit. Now it’s time for them for the baptism of fire!
How long will this be goin’ on?
There are no golden rules on how long such a trial should last. Clearly, it has to be long enough for you to test your development-team-to-be in the following aspects:
- How they work (flexibility, on-time delivery, code quality, attention to detail, engagement)
- How they communicate (responsiveness, transparency, articulateness, fluency)
- How their solutions work (if they walk the walk).
We’ve learned through experience that often one sprint is enough to assess a company in the above areas quite accurately. And that’s exactly how it works in NeuroSYS. A run-of-the-mill development trial, with no strings attached, lasts 1-2 sprints, which is 2 up to 4 weeks. However, it can take more now and then, which depends on the type of task carried out. We had a client with a 3-month trial as well.
How to choose a development task
Keep it small. Look for assignments that are simple and their desired effects easily defined. Then the verdict is unequivocal: the feature works = we cooperate with the provider, it doesn’t = we need to continue our search.
Keep it challenging. Small doesn’t mean it has to be easy as pie. Only more demanding tasks will show you how the team overcomes problems, communicate with you – and if they’re capable of developing your application long-term.
Keep it applicable. Choose a feature in your own backyard. You want to test your company on a living organism and not on imaginary tasks.
Is a trial free?
Most certainly a development trial won’t be free of charge, at least it isn’t in the case of our company. The reason is simple – it involves a number of IT experts on our side, from developers, UX/UI designers, to scrum masters/project managers. Working for several weeks for you. Communicating with you daily (if you wish so). Handing you the results of their work you can use them freely later on – source code, documentation, mockups, and outlines.
PS
Still, we offer free consultations, during which we discuss your project in detail. Feel free (pun intended) to try it!
The major benefits
Above all, the development trial aim is to minimize the risk of working with a new software provider. You can verify them in terms of their work quality, communication, transparency, and whether you just work well together with no long-term commitment. The moment the trial ends, you simply say Adios! and start looking for a more suitable software agency. If you’re still not convinced, you can always verify the code quality, development process, and tasks with an external expert.
Sometimes the problem lies not in the software quality itself but in the project management or communication. There’s no other way to verify it than to start working with each other. And since the cooperation can take months or even years, it’s better not to leave out this step.
The drawbacks
As always, it’s complicated. There are no drawbacks if you’ve got a simple feature that can be developed and thus your software provider adequately tested. Even if you won’t decide to prolong the cooperation, for a variety of reasons, there is no significant risk involved. What are a few weeks compared to the months you’ve saved this way?
Worse, when there is no simple task to take on or the project entry threshold is large (a complex project to develop or rewrite). There are a few ways of dealing with a situation like this. The simplest, most natural one is to extend the trial period. Surely, your provider will come up with more good options, based on your particular case.
Just before you start…
On a side note, before you sign NDAs and grant access to your documentation, make sure you own the code and all other visible effects of the trial. I won’t rant about it here, hence more on the topic you’ll read in the separate post on code ownership. Just to make it clear, a good software development company will have it already included in their contracts.
To sum up, if choosing a software company gives you the willies – try development trial. It is an effective and relatively quick method to verify your contractor before you engage in a serious relationship. Good luck with that!
]]>Start with a why
Before we focus on story points, let’s take a moment to introduce the tool used in Agile software development. The programming process is carried out by completing tasks, which are often described by user stories.
User stories answer who, why, and how questions in the context of software requirements. They’re not stories in the common understanding, long and detailed. Usually fitting onto index cards, post-it notes, or in tabs of dedicated software, user stories are clear and concise.
Software development projects need estimations to answer inevitable questions, emerging on the clients’ side – how long will it take, how much will it cost, how many programmers will I need?
Once we know the hows and whys, we divide the project into tasks to be done, and that’s where story points enter the stage.
Story points – what are they and where do they come from?
In project management, story points are a metric used to estimate the difficulty and complexity of implementing given requirements. The approach originated from the Extreme Programming methodology and became successfully adopted by Agile professionals.
The size of stories is not estimated in hours, days, or weeks of development, but story points (SP). For instance, a story with 1 SP is smaller than the one with 3 SP.
This estimation doesn’t indicate however the time necessary for the delivery of the desired result.
And we can’t stress that enough.
It’s a common project mistake to convert story-pointed tasks into hours. We strongly discourage this because story points do not translate directly into spent time. Story points are meant to reflect the dependencies and complexity of project tasks, not bare man-hours spent. As such, they present a more realistic prediction of the effort necessary to deliver tasks and projects. Story points are an answer to clients demanding fast/good/cheap execution of their projects. Most cases happen to be rather fast and good (or good and cheap) than all 3 at once. This approach puts more emphasis on delivering quality, not cutting costs by all means.
Story points indicate the complexity of upcoming tasks.
The focus during estimation should be on:
The volume
How much work and effort will be required?
The complexity of the issue
Is the item more complex than tasks of similar volume? Does it entail special handling (highly specialized knowledge, uncommon practices)?
Potential risks
Are there any identified unknowns and uncertainties? If so, are they addressed by managers prior to the project launch?
Team’s proficiency
How experienced are the team members in fields necessary for the projects’ execution?
Dependence on external parties
What necessary areas need to be addressed on the client’s side, e.g. APIs structure?
Do story points give clear answers?
Story points do not indicate expected costs or delivery dates, and as such, are considered by some to be problematic. While the approach itself doesn’t illustrate costs in a linear way, once project teams work out SP estimations, another metric can be used as a guideline.
Velocity allows estimating the cost of developing a certain number of story points per sprint. Describing what the team can deliver within a specified time, velocity reflects the number of story points delivered in each sprint. Keeping it in mind prevents project managers from packing sprints to the full with critical issues, leaving a buffer instead. This way, aside from focusing on core tasks, developers can use the potential spare time to include additional commitments and focus on technical maintenance, improvements, or paying the technical debt, once priorities are completed, but without the pressure to complete all tasks in unrealistic estimation.
Velocity reminds managers of dropping the default value of full 40 hours per developer weekly, as story points take into account all aspects not necessarily covered in time estimations. Breaks, daily meetings, and retrospectives aren’t coding, but all make up for developers’ working day, affecting the end result.
Issue:
Using story points may cause developers to increase their estimates habitually, impeding the general assessment of projects’ scope.
Solution:
Measuring velocity enables managers to monitor the pace of work and assure the estimated values remain corresponding to delivered features.
Are story points useful?
Story points reduce planning time and help improve the team’s performance. They are precise enough to plan sprints ahead (since we know how many story points can be delivered per sprint), allowing time expectations management in future work.
The downside of story points is the occasional lack of an intermediary value between e.g. 3 and 5 story points. When the higher number is chosen, time and effort saved up in the buffer can be compensated by adding additional tasks at the end of the sprint. The necessary condition for such a solution is the initiative of both developers and PMs.
Story points eliminate the need for frequent re-assessment of estimates, acting towards under/overestimating in the general sense. Being more general than time evaluations, they allow including more uncertainty in task assessment and a greater unification between team members.
How to avoid mistakes using story points?
- Don’t translate story points into hours
- Don’t adjust story points to team members
- Reduce risk and uncertainty prior to estimating
- Assess incorrectly story pointed matters during retrospectives
- Keep velocity tracking and make sure it is stable or increasing
- Discuss story point value definition with the team and provide a common understanding
- Make sure that the client is aware of the value behind the story point estimation approach
Should you use story points?
There are plenty of reasons to support the idea of story points, and we can list the most compelling:
- Avoiding rigid deadlines
- Improving commitment
- Focusing on quality
- Improving adaptability
- Boosting performance
- Minimizing technical debt
To be fair, let’s not forget about the arguments against using story points:
- The estimation of spent effort is not equivalent to spent time
- The approach is unsuitable for short-term works, as it takes more time to work out estimations in story points
- Story points require more trust to the teams’ members from the management
- SPs take more time to convince clients to use this approach
Pros outweigh cons (it depends, however, but we’ll get to that in a moment), and if carried out with care, story points contribute greatly to project execution. As for convincing clients, we prefer the show, don’t tell method. Presenting how velocity reflects task delivery is more effective than just describing the approach. When it comes to persuasion, we present a trial estimation of story points and velocity, as clients are best convinced by seeing tangible results.
Still, SPs are not a miracle cure, and as such, sometimes aren’t the right approach to take. They are a tool, and as in the case of other utilities, it’s crucial to select the most suitable instruments for the project for its most beneficial execution and not the other way around.
Especially in projects limited in time (depending on e.g. timeliness imposed by clients’ obligations to third parties) and more on the short side, time estimations may be more beneficial. This counts also for minor projects, performed sometimes by solely one programmer. In such cases, the traditional approach to assessing tasks is sufficient.
How do we measure tasks in story points?
Our developer teams measure tasks together, yet secretly. This way, each team member can assign the most adequate value, based on their expertise. Developers often use the PlanITPoker app, an easy tool supporting the assessment process.
The final number can be later on voted as too high or too low if some ratings significantly differ from the average value. Estimates are built on the consensus and the entire group’s insights, and as such, are more accurate than evaluations based solely on time expenditure. Risks related to estimating story points decrease over time the team cooperates. Experience gathered in projects is proportional to a shared understanding of story points value and curated by the manager, helping developers each time misconceptions arise.
Story point values can be assigned as the example shows:
Story points 1: Low complexity, little time needed, no new functionalities
Adjustments, small bugs, minor refactors, small frontend changes.
Story points 2: Low complexity, new functionality
The lowest possible estimation to be given for new functionalities and default estimation for bug fixing.
Story points 3: Normal complexity, new functionality
Standard tasks related to new functionalities. No bigger uncertainties related to the ticket. Usually, both frontend and backend work is required.
Story points 5: High complexity, new functionality
Not as uncertain and complex as 8 but not as easy as 3.
Still, a regular ticket but requiring more work than 3.
Story points 8: High complexity, new functionality, new domain
There are a lot of new topics to be explored within the task, the amount of requirements is very high, or the dependencies within the system are high. 8 is the highest estimation possible to give before we split the ticket, so we should ensure that the investigation happens before and that all the uncertainties that were possible to resolve were covered.
Story points: higher – split into smaller tasks
The final judgment – should you use story points?
Maybe that’s not the answer you were looking for, but…it depends. We work with traditional estimations and story points, both serve our projects well. Unsurprisingly, the secret is recognizing when story points will be the most beneficial to work performed, and when time measurements are just fine. Just like the eternal rivalry between the waterfall and Agile methodologies, each approach has its pros and cons, and it’s our job to make the best of them according to the needs.
Are you looking for a digital partner to create your project with? Book your 1-hour free consultation to see if we’re the right match and learn more about the best approach to your ideas.
]]>The biggest misconception
It’s a common fallacy that you can plan everything in a project in advance. Nothing could be further from the truth. Firstly, because we aren’t the best at estimating the amount of work that has to be done (we’re way better at comparing tasks). Secondly, we should adjust and refine the plan throughout the project. Thus, we divide projects into smaller, feasible bits and define work priorities.
INVEST in stories
The key to a good estimation is a precise definition of the requirements. We can achieve this by creating user stories. User stories explain features in a general way, from the perspective of the end-user, demonstrating their real value. Creating them with your team remember not to use technical language – stories should sound as natural as possible to facilitate team communication. Above all, post-planning tasks should be clear to the team.
The most common template for creating user stories, though not the only one, is:
As a [role, e.g. client, product owner], I can [capability, e.g. browse items, monitor client behavior], so that [benefit received, e.g. I can find what I like, I can offer clients best-fit products].
Let’s take our learning management system Samelane as an example. The user stories can look like these:
– As a learner, I want to browse all courses available, so that I can find the most valuable ones.
– As a learner, I want to get notifications about course deadlines, so I can complete them on time.
– As a team manager, I want to be able to track the learning progress of each employee, so that I can offer them help or praise their achievements.
To make sure your story is ready, we use INVEST criteria. Thus, the story has to be:
- Independent – it can be realized on its own, it’s not dependent on another story, so we can change its priority freely
- Negotiable – we can still discuss and improve it if some requirements change
- Valuable – it has to add a value of some sort – to stakeholders or end-users
- Estimable – we have to be able to evaluate its size so it can become a part of an iteration
- Small – its scope has to be small enough to plan its development easily and accurately
- Testable – there has to be a measure to check whether it works/has been realized.
Prioritization
All requirements might seem important, but we can’t deliver everything at the same time. Functionality hierarchization helps us determine what will bring the greatest value to the project. For functionality to be taken on in the next sprint, a product owner together with a client should identify priorities of individual requirements.
Tip 1
It’s important to go through the prioritization process before sprint planning. It will allow the team to plan its work in a way that will reduce the risk in the event of failure to deliver key functionalities.
Tip 2
Provide your team with the list of prioritized tasks before the refinement or planning. This way they can get acquainted with them, prepare questions and initial technical solutions.
Must, should, could…
To make sure that priorities are identified properly, you can use the MoSCoW technique. It allows you to separate requirement significance easily based on four categories. MoSCoW is often used in agile software development when deadlines are fixed (timeboxing) and the team has to focus on the most important functionalities only.
These four categories are:
- Must have – critical in the ongoing delivery
- Should have – important though not crucial
- Could have – desirable but far from critical
- Won’t have – can be dropped at all or included in the next sprint
An example of MoSCow technique when building a particular functionality – here registration:
| Priority | Description | An example |
| Must have | If the requirement isn’t achieved, the functionality won’t be valid or function properly. | Password validation, verification if the user already exists |
| Should have | The requirement is important but doesn’t jeopardize the legitimacy of the business functionality. | A thank you email that is sent after registration |
| Could have | The requirement will increase business value but its lack won’t be noticed by the end-user. | Registration with a Google account |
| Won’t have | Requirements that are legitimate for functionality, but will certainly not be addressed in the following sprint. | Registration with a Facebook account |
The client vs the team
It might happen that the priorities chosen by the client aren’t in line with the development team’s technical needs. Why is that? The devs’ order may result from technical dependencies between the tasks. Commonly, teams force particular task realization to keep the code in good shape. These are tasks often related to refactoring or paying technical debt off.
Naturally, clients won’t see business value in such tasks because they don’t bring tangible effects (though the consequences can be grave and they should know about it). As always in similar situations, the way out is communication. The client and the team have to come to a compromise to fulfill both sides’ tasks, not to build technical debt up.
Sprint planning
In Scrum, every iteration ends with a value that should bring the product closer to succeeding on the market. Thus the tasks are organized according to their business value. The overall plan can be adjusted if the product doesn’t go in the right direction.
Sprint planning takes place (surprise, surprise!) during a sprint planning meeting, in every sprint. Knowing the sprint’s aim, the team meets to decide what they can achieve in the following weeks. To do so, they analyze tasks defined in the backlog and create a delivery plan.
During planning meetings, the following elements may affect the course of the sprint (worth taking into account!):
- holidays
- dependencies between tasks
- project resources
- dependency on external entities
- time for product releases
- meetings
- taking care to minimize the technical debt.
Based on previous sprints, we should be able to quite accurately estimate the next one. For example, if a team of 4 developers delivers on average 20 story points/a sprint, when 2 devs have a holiday, 2 left should in theory provide about 10 story points.
It is worth noting that the key in sprint planning is to leave a buffer that will allow you to respond to changes, fix bugs, adjust after a code review, etc. While the drive to increase velocity is important, we should always plan in a way that the sprint goal is not threatened.
Here’s an article on distributed team management using Scrum, which you might find helpful as well.
Planning poker
Planning poker, or Scrum poker, is a quick and reliable estimating method based on consensus. Team members make estimates playing cards with numbers from the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.). If the revealed cards are similar, up to three consecutive numbers – we calculate the average. If there’s a greater spread, those who chose extreme cards explain their decisions – and the team plays poker once again. It’s worth noting that the method is used for estimations not developing definite plans.
That’s it for now. I hope you’ll find these methods useful and if you’d like to find out more on Scrum, here is Welcome to Scrum part 1 and Welcome to Scrum part 2 articles.
]]>