Why hire agile software development experts?

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

Agile organisations are able to respond to changes quickly and efficiently. That ability is critical to succeeding in an uncertain and constantly evolving environment.

Forbes reached out to more than 500 senior executives from around the world and asked them about agile. A smashing 92% of them said that organizational agility is critical to business success.

 is a strong trend that has become an industry standard all over the world for some very good reasons.

Agile Software Development is an umbrella term for a set of methods that reflect the values presented in the Agile Manifesto. But it’s basically about developing solutions through the collaboration between self-organizing and cross-functional teams.

Agile is an industry standard. Stack Overflow recently surveyed over 100 thousand developers, and 85.9% of them said they use agile in their work.

Why choose agile sthaoftware development?

Agile methodologies allow organisations to address customer needs efficiently and optimize the process of building software.

Here are some of the benefits agile brings to organisations:

High quality - in agile development, testing is an integral part of the development cycle. Teams are always checking whether the solution works well and make changes when needed. Using sprint retrospectives, teams can continuously improve their processes and work to create even better software.

Customer satisfaction - agile teams always have a product owner who ensures that development is transparent and flexible. It’s easy to engage customers in the development projects - you can show working functionalities to customers in every sprint review, and deliver products to market quicker and more often

Reduced risk - team that use agile minimize the risk of project failure significantly. Developing in short sprints ensures a short time between initial project investment and adjusting the approach to solve problems and eliminate risks. Agile also helps to generate revenue early on.

Faster ROI - agile development is iterative, which means that the features are delivered incrementally, offering organisations a chance to realise benefits early, even when the product is in the development process.

Focus on business value - in agile, it’s the team deliver features according to the priority set by the client’s business needs and goals.

Organisations looking to develop software solutions should consider agile methodologies as one of the factors in their choice of a technology partner.

Software development companies that use agile follow practices such as iterative and incremental development. They deliver small chunks of functional software that can be tested and checked against business requirements regularly. By providing regular feedback, organisations get a solution that matches their business needs perfectly.

At Solidstudio, we have been using the agile methodology for many years with great success. We have implemented key best practices and industry standards to deliver high-quality solutions to our clients quickly and efficiently.

Our experience in agile software development.

Avoiding the pitfalls of the traditional waterfall method of developing software, our team of experts makes the most of agile to deliver solutions that help our clients solve problems and achieve their business goals in a lean and sustainable manner.

Are you looking for an experienced team of agile software developers for your project? Get in touch with us.

Agile is becoming an industry standard all over the world for some very good reasons.

5 benefits of working with a nearshore software development company.

If your technology business is rapidly growing and you need new people on board fast, you’re probably considering to outsource development to manage the workload. 

 allows companies to hire skilled developers who can handle even the most advanced aspects of a tech project to let your internal team focus on the big picture.

Nearshoring is one of the most popular form of outsourcing software development or services today. That does not come as a surprise because nearshoring offers many different benefits.

Here are 5 reasons why companies team up with nearshore technology partners:

By partnering with an external company, you get to benefit from the talents it has sourced and nourished for a long time before they join your ranks. You’ll be working with an external team of developers who have previously collaborated and have processes in place to enable smooth development. Hiring a team like that would take you a lot of time and resources.

Nearshore partnerships offer flexible options for scaling your IT team as needed. You may need developers for your project right now, but your needs may change after 2-3 months. Hiring nearshore allows getting the work you need, right when you need it.

Most of the time, nearshore professionals follow the same industry standards and best practices such as agile or scrum. They work on similar timelines, and you have little to no gap between time zones.

Finding qualified talents for your internal team is always challenging. When you team up with a software development agency that builds a team for you, you remove all the hassle that comes with sourcing, attracting, and recruiting developers. You don’t need to spend a dime on the hiring process.

Reducing communication issues that are usually part of outsourcing development helps to improve the ROI and bottom line. In nearshoring, you benefit from reduced language barrier between supervisors and nearshore developers. For example, in Poland pupils start learning English in primary school and are proficient at it by the time they graduate from high school.

How to choose a nearshore software development company?

Hiring a company in a neighbouring country or relatively nearby is different than teaming up with an offshore partner located on the other side of the world. Hiring a nearshore partner is more comfortable, but there are some things you should be aware of when looking for the right technology partner.

Check their knowledge of English or another relevant language - you need that skills for smooth communication. Remember that communication problems may kill a project quickly, especially if we’re talking about the complex process of building software.

Ensure that the company has skills and experience you see - it only makes sense to enter a nearshoring partnership if the partner offers expertise that fills the skills gap you’re experiencing internally. That’s why checking the company’s areas of expertise is so important.

Nearshore development - the current hot topic.

Delegating development tasks to a nearshore development team allows your company to concentrate on the big picture and create a real competitive advantage. Tech giants like Amazon or Apple are aware of the benefits of nearshoring and are increasingly turning to nearshore development today.

Hiring nearshore software developers is on its way to becoming the standard workflow of the future for companies that experience rapid growth and need a sustainable solution to support it.

Don’t leave your company behind and take advantage of nearshore software development. Get in touch with us to see how our team of experts can help you solve problems and achieve new business goals.

Nearshore software development.

Needs evolve with technology, people, & processes.

At some point, almost every startup is faced with the outsourcing decision. Whether your company would benefit from outsourcing some or all of their development to a trusted partner depends a lot on individual circumstances. If you are considering outsourcing, there are a few questions you should get answers to and a few things you should consider before making a decision.

Outsourcing falls into two main categories: adding to your existing and total outsourcing.

Scaling up your current team or setting up a complementary development team that works closely with your internal IT department or another department within your organization. This option is great for established startups that need to scale their operations or access developers with skills their internal team doesn’t have. This form of outsourcing lets companies access a pool of experienced developers with a wide range of skills and quickly scale up development as needed without committing to hiring more internal team members.

Total outsourcing involves relying on an external partner to support all of your development needs. This is a great option for smaller companies that don’t have the budget to support an internal team. In this case, the technology partner handles the entire development pipeline, including implementation, testing, and deployment.

Why Should My Startup Consider Outsourcing?

There are a few reasons companies consider outsourcing. Outsourcing allows your company to quickly and easily scale your development team up or down to meet your changing needs and requirements without the hassle and cost of in-house recruitment. Outsourcing is also a great way to add necessary skill sets to your team, particularly if a select skillset is only occasionally required.

Partnering with an experienced development team that understands your business goals is vital, particularly if your startup is still in the early stages. Having a steady and experienced team on your side can help you achieve your goals.

Choosing the Right Development Partner to Suit Your Needs

Every startup is unique, just like every development partner is unique. Finding a partner that works well with your team and can meet your unique needs is vital for success. While some aspects of development, such as good UX design or solid project management skills, apply to all projects, you need a development partner that can tailor their skills and expertise to meet your needs. A good partner will finish all the tasks you assign them, but 

 will work with you to identify potential growth areas, offer suggestions and advice, and help you achieve both your short and long term goals.

To help our partners succeed, Solidstudio offers a wide range of 

, to help potential partners clearly identify their needs before committing to the partnership. We also host workshops to help our partners identify their true business needs and help them determine what steps they need to take to achieve their goals. Choosing a partner who looks at the big picture and is able to support both your current and future needs in the IT product development sphere is essential for a successful, long-term partnership.

The ability to scale quickly and seamlessly while keeping development quality high is at the core of any great development partner. Startups move quickly, and you need a development partner that can keep up with you.

When working with a new partner, it’s vital that you see the value add from the very beginning of the relationship. Your development partner shouldn’t only be interested in the number of hours they will need to work or which resources they will need to commit to you and your projects. Instead, look for a partner that focuses on how they can help make your product, and your business, better by assisting with things like planning and assigning out work to the right resources for the job.

You should also make sure you choose a partner whose values and attitude match your company’s culture. Cooperation is key to the success of any project, particularly in the fast-paced startup world. It can be difficult for teams to work together if their values and corporate cultures aren’t compatible, so look for a partner that cares about the same thing you do.

One organization the Solidstudio team partnered with was a Berlin-based, rapidly-growing startup in the 

. This startup already had an internal development team, but they needed access to additional skills their internal team members didn’t possess, leading them to partner with Solidstudio. Our team is currently working with them to finish their partially completed solution and now provides full development support for 3 additional projects to address the pressing needs of their clients.

We were also able to facilitate the migration of their app to the cloud and help them architect their platform using micro-services. We are also working on implementing best-in-class cloud solutions. In addition to helping this client achieve their goals, we also helped them fundamentally change how they approach development by assessing their team and their needs and introducing them to the agile method.

Our team partnered with a company that had no internal development resources to provide total development support in this case study. 

 is a UK-based company in the health and wellness sector that was looking to develop a web-based application to help their customers track and improve their well-being.

Our team worked with them to create a minimum viable product (MVP) and continue to offer ongoing support using a variety of tools and methods, including planning, workshops, and backlog development through the implementation phase. We also handle their hosting.

Whether or not your startup should outsource their development (either partially or totally) depends on a lot of unique factors. The Solidstudio team is here to help you identify your core needs and craft solutions that allow you to achieve your goals, all while providing ongoing support and valuable advice.

Needs evolve with technology, people, & processes. Click to read our article.

What Today’s Startups Need From Their Outsourced Development Partner

Event storming is worth a shot and here is few reasons why.

Having a chance to work with well-established startups from the e-mobility sector, Bartek gained invaluable knowledge on the industry requirements. On his path, he was given the opportunity to work on numerous EMSP applications and CPO platforms. Bartek is also our Head of Delivery.

Bartłomiej Łazarczyk

Most developers already had the chance to hear or read about Domain-Driven Design. Long story short, this approach is meant to help in modeling complex domains by offering precise tools and encouraging the use of specific, domain-oriented ways of thinking. It is a powerful methodology that works perfectly well with greenfield projects. But what about a legacy system that was, in addition, poorly designed and maintained? The cost of introducing this approach to the entire company is huge, takes a lot of time, and requires some training courses (not only for developers). Thankfully, there is a simple technique invented by Alberto Brandolini called 

. This is a good starting point for discovering Domain and introducing DDD.

Recently, we have started to implement the Domain-Driven approach together with one of our clients, and our goal is to integrate processes for discovering domains based on different Event Storming workshop variants. In the wake of a few sessions completed so far, we have reached some insights, and we would like to share some of them in this article.

First, let's focus on the workshop itself and its most popular variant, Big Picture Event Storming, with its basics and how to facilitate it. The main goal of this workshop is to gather all people that have a business, domain, or technical knowledge in one place and model the current understanding of the system.

You might say that there is nothing special about it, right? There are many other workshops and techniques that accomplish the same, so what makes Event Storming special?

The biggest advantage that speaks in favor of Event Storming is the clear, easy, and structured way of communication between employees from different company units. And because of that, we can naturally stimulate our participants to start a dialog, discussion, share thoughts and, most importantly, to agree on the language and discover it with us.

To perform this workshop and make it successful, you need three key ingredients:

The right people - a greater variety of the group, may color the final view by reducing bias, but be sure to invite only those people who have the most influence or knowledge about a given subject and care about the problem. They will be your domain experts. Developers with long service can be useful experts too, but they need to understand that the event should be considered as business-related.

A good location - the room needs to have at least one long wall and be large enough to accommodate gathered people and give them some space.

An experienced facilitator - you need a person or two who will ask the right questions, timebox every phase, and be able to explain all the rules and stages clearly so everyone would understand them.

As I wrote before, the room needs to have a long, straight wall on which you will be able to stick paper rolls. The bigger the wall, the better. At least at the beginning, all the participants should have space to stand and walk, so you also need to move all the seats to the place or corner, which is not easily accessible. The next important thing is a table with a lot of sticky cards in different colors, a few markers and a board with a legend of what each card means.

Sticky cards are the best tool used in the meeting. In the Big Picture variant, we can differentiate between five types of cards.

Orange cards represent an event and are the main building blocks in our process. To be more precise, this is an event relevant from the domain expert perspective. Events should always be phrased at past tense. Example: Report was generated, Charging has stopped.

The yellow card represents people involved in some event or process. You can treat it as an actor as well. Remember that the goal is not to specify people for each event but to accentuate the involvement of someone outside of the system. Example: Portal user, Support team member

The violet card represents the system involved in some event or process. It can be either an external or internal system. The same as in the card for people, the clue here is to emphasize some external involvement. Example: Third party API, Database

The red card represents a hotspot. This is used for marking a place with the lack of proper knowledge, something that is not working well or to mark a place of disagreement between participants. This is a sign that we need to take a deeper look into it later. Example: Generating report takes to long

The green card represents an opportunity. It can be used for specifying something that is already working quite well, something that we can improve, or some other handy ideas. It can be a good alternative to the hotspot card for an attendee who prefers resolving problems rather than complaining. Example: Delivery reception can be automatized

Up to this point, we have a place to organize the workshop, we have the tools - but what is the process itself? To quickly answer this question, there are five different phases in this meeting:

To benefit from our long, carefully prepared paper board, we need to draw a small timeline at the top of it, explain what each card means, ask everyone to think about some events happening in the system, write down an event on the orange card, try to stick it somewhere on the timeline and do it again and again until everyone runs out of ideas. It’s easy as that! Nevertheless, we often run into a problem with starting to stick cards. In that case, you need to encourage everyone or place an example card yourself to show that it’s just placing a card on the board, nothing more. Since it’s chaotic exploration, the location on the timeline does not have to be 100% accurate but will be helpful during cleanup. This phase should not take long; if you see that no one is writing anything on the cards for more than a few minutes, you can just finish this phase. In the end, it should look more or less like on the image below.

After chaotic exploration, of course, we need to do some cleanup and sort out all the events we have gathered on the board. Unfortunately, it’s not as easy as it sounds. Some parallel processes will surely come up, people will try to kick all events around, and a lot of confusion will happen. To make this phase nice and effective, we can introduce some structure at the beginning. There are quite a few good strategies, but we highly recommend specifying a few pivotal events and introducing swimlanes. We ask our domain experts to choose up to four-five most significant events in the flow. They don’t have to be perfect; it’s enough if the other sequence of events is depending on some pivotal event and cannot happen without its occurrence. That will create a framework on the board, which makes sorting other events easier by determining whether they happen before or after a given pivotal event. We can introduce swimlanes for all sequences of events that can occur at the same time. When everything is put in order, it’s good to make a walkthrough from the first card to the last and assure everyone that they did a great job.

In this phase, we ask our domain experts to specify a few people and systems which play some role in the events. We need this information to have a full picture of the serious dependencies in the given system. It may also point to a place where there is no full control in the system, or where constraints and conditions are present.

So far, we have quite gained a lot of data about our domain, but still, it doesn’t feel as solid and detailed as it should be. To encourage our participants to be more creative and take a different perspective, we should spend more time on the backward walkthrough phase. In general, we need to ask someone from the audience to read out loud all the events starting from the last card. What is different now is that we ask additional questions like:

Is there something more happening between X and Y?

These questions will make domain experts think in different ways, stay focused, and not take something for granted. As a result, we will have new information and more details - and therefore, new events, new flows, and new structures. The most important rule here is to discuss and fill the magic gaps between events if they are apparent. There might be a situation when an agreement cannot be made due to a lack of knowledge. In that case, marking it as a hotspot is a good choice.

The last phase could be optional, but the overall picture of the system will gain a lot from that information. We would like our domain experts to specify hotspots - aspects to improve, and opportunities - ideas to introduce. After that, we organize short voting by drawing an arrow near the most important hotspot/opportunity in the system. This information is a very important sign that in any further discussion, we need to dig deeper into this area and try to solve this problem. We can also prepare a simple metric for a given hotspot/opportunity so it can be expressed with numbers, and as we know from our experience, numbers are intrinsic for business.

As you have already seen, this workshop is not so complicated from a technical perspective and probably could be performed by anyone who knows its rules. However, just as in real life, details play the biggest role. Some obvious behaviours and attitudes are often forgotten in effect, so here are a few tips that came along with practice.

Event Storming is all about the people and their knowledge. The goal is to have as diverse and useful a group as possible. To achieve that, a simple stakeholder mapping technique comes in handy. We need to find a person who knows the system and the company quite well. It can be a Product Owner or someone from the management board. Then, together, try to determine potential participants on a simple figure with two axes: influence and interest. For simplicity's sake, we can divide the figure like in the image below and map people into those areas. The conclusions are self-imposed.

Remember to make the goal of the workshop clear to everyone, especially in the Big Picture variant. People often tend to lose their track if they don't narrow the scope a little by having an explicit reason for carrying out the workshop. That may result in many wrong, or irrelevant events, so unnecessary confusion could happen by accident in further phases.

A good facilitator is priceless and makes a huge difference during the workshop. Leading a workshop is a skill that demands time and experience to be improved, but fortunately, we have some advice on that matter (especially useful if you're just getting started).

At first, keep the meeting and rules in scheduled bounds and don't allow too much freestyle. Boundaries trigger creativity and require mental effort. The next thing is about too specific questions during the Big Picture Event Storming. Not everything is important and necessary at this level of abstraction. More details should be discovered later when the scope is limited, and we have a clear goal to deliberate specific aspects. When something is not clear, just mark it a hotspot.

The last and most important thing is to focus on the language that springs out during the discussion. Domain-Driven Design puts linguistic differences first, so try to pick up details and attributes up as much as you can. Ubiquitous language is necessary to appoint subdomains, and there is no time to write down everything that has been said.

If you gather people from different company units, they could have their own definition of an event. It is really important to have a common understanding that events should be relevant from a domain expert and from a business perspective. An event should not be connected to some implementation and technical concepts because it's highly probable that it doesn't reflect the problem and domain. Often, it is far and away from the business-related issue, especially when you are considering a legacy system that wasn't designed in a Domain Driven way.

Do your best to specify good pivotal items. Ask as many detailed questions about chosen events as you can, e.g., "Are there some events that cannot happen if this event has not occurred?", "Is it necessary for some processes to start and go on?", etc.

This will speed up the cleanup phase, and in the future, it can point to a moment when the language is changing. Pivotal events often come with new processes that could be related to different subdomains.

It's hard to book at least three hours in everyone's calendar. It's even harder to stay focused and feel good during such a long meeting. Proper timeboxing and breaks are a must. Spend your time, more or less, in these proportions:

Chaotic exploration: about 10-20% of time

Enforcing the timeline: about 30-40% of the time (cleanup takes some time)

Backward walkthrough: 30-40% of the time (most of the details come up here)

Hotspots and Opportunities: max 5-10% of time

People would love to see the result of spending their precious time on discovering their domain. Also, from the perspective of a software architect, you need to have a better overall view and possibility to manage it without effort. Digitizing it seems to be the best solution, and for that, we recommend an online tool called Miro. It has a feature to capture sticky cards and convert them to online notes, which can save a lot of time.

Now that we have finished the workshop, everyone is completely exhausted but also satisfied with what they have achieved. And then they ask the important question: What is going to happen next?

The answer is simple. Now it's time for the domain architect to discover and validate the subdomains. We have a big picture view of the whole system, but we don't understand it yet, we cannot tell what exactly is happening underneath, what problems there are, and what exactly we want to solve.

We need to determine emerging subdomains. It's not easy; some even say it has more in common with art and intuition rather than logical patterns and equations. What's more, there are dozens of heuristics and techniques for doing it, and none of them are universal.

Nevertheless, here are a few worth mentioning.

This can be a good entry point for further considerations. Each organization has different units that can reflect different subdomains. Unfortunately, business processes, which are a part of the core domain, often cross different departments, so we cannot rely on this heuristic much.

It's a common situation that within one company unit, there are few domain experts responsible for different issues. This is a clear sign that we may expect different problems in one place and may need different subdomains.

Probably the most important and practical heuristic, which assumes that words and terms have a different meaning in different contexts and subdomains. Company products have different meanings in the sales department and different meanings in the warehouse department. If we don't focus on the language, we risk failing to see these various perspectives, life cycles, and issues separation.

If some aspect comes with huge business value, it should probably be a separate subdomain. You can be almost pretty sure that this aspect is connected with the core domain, the company determinant.

Many business processes often involve different subdomains. Establishing factors that highly influence the process may point to a change of involved subdomain. Finding that might require introducing a clear chronology and asking for more details about what is happening between two events.

Agile software development

06 DECEMBER 2018 • 5 MIN READ