Welcome to Equalminds – The Agile Crew
We help organizations meet their challenges in the field of Software Development.

Get Started


Agile Team

Our team of consultants consists of a number of agile business analysts, agile user experience designers, Scrum Masters, Product Owners, Scrum Trainers, Coaches and very experienced agile software development specialists. These development teams consist of experienced and very experienced IT experts and are divided into different specialties, domains and technologies.



We use and have knowledge off multiple project management tools.
Our consultants have in depth knowledge of at least one of the following tools in order to manage your project:

Atlassian (Jira, Greenhopper, Confluence and many add-ons), Pivotaltracker, TinyPM, TargetProcess, VersionOne, RallyDev, and many more…



Our belief is that creating the right development team and a collaborative environment is the most important aspect in creating software but at the same time technology is an important aspect as well. Using the right technology for developing a solution can shorten delivery cycle tremendously and at the same time can create some very valuable offering to the users. Equalminds believes in innovation and in adopting and executing solutions based on new and advanced technologies.
We offer custom software development solutions using an array of technologies and agile methods. We have a large network of agile technology experts who know how to develop in an agile way.



Microsoft Technologies:
C#,ASP.NET, Silverlight, WCF,WPF,WWF, Sharepoint, Sitecore
Java Technologies:
Core Java, J2EE, J2ME, Frameworks like Oracle ADF, Sprint, Hibernate.
Open Source:
PHP, Drupal, WordPress, Umbraco, Liferay, HTML5, JQuery, JavaScript, …,
Mobile Application Development:
Cross Platform Development for iPhone, Android, Windows Mobile, PhoneGap, HTML5, Moble JQuery, Sencha Touch
Microsoft SQL Server, IBM DB2, Oracle Server, MySQL

Agile Business Analyst

What is Agile Analysis -?

Agile analysis is ever increasing, in the world of business. As businesses progress and develop this type of analysis becomes more sought after.
This type of analysis requires a more involved hands on approach. It requires more communication and there are regular face to face discussions. Due to this regularity using E-mails are becoming less utilized.

So What Exactly Is The Agile Business Analyst Job Description?

Agile analysis pertains to business trouble shooting. This is a hands on approach, and the stakeholders that request this type of analysis are more savvy than most other managers.
The process of agile analysis requires the incorporation of all the stake holders into one unit, they will all have their own given task.

There is always an open channel for communication, during any agile analysis process. The business analyst will have a great dependence on their people skills, unparallelled to any other analysis process.

An Overview Of Basic Business Analysis

With a general business analyst there are questions that need to be answered such as:

Who is it being used for?
What is required?
Why is it required?
When is it required?
What is it going to cost?
Where is it going to be used?

If the business analyst can answer these questions with all the data gathered then solving the problem becomes a much easier task. This is not so with agile analysis.

The Phases Of Agile Analysis

Using agile analysis is more personable, so there is always constant communication with the stakeholders. This means there will be more personal contact opposed to e-mail.
The stakeholders will have a more hands on involvement in every step of the development process with the business analyst.
This means the business analysts team and development teams will work closely together to deliver the right software quickly.
The development team will receive face to face feedback, which will allow them to make changes for the client more intuitively.
There will be a model structure that will target all the phases, all results will be classed as just in time solutions.
Throughout the stages the stakeholders will immediately be able to determine compatibility. They will be able to decide whether the phases will work within the guidelines and scope of their determined project.

During each phase meeting there will be questions and answers for the teams involved. This makes it clear to all parties what is happening and what is going to happen.

The Advantages Of Agile Analysis

The use of Agile analysis has become more popular over the years. Customers find that they like its quick approach to resolving issues.
For the ambitious and personable business analyst, Agile analysis provides closer contact to the stakeholders and less room for error.
The close communication is especially appreciated by IT departments as they can write code that is more than likely going to be utilized.
Agile analysis can also be more cost effective, which make it a winning situation for both business analyst and stakeholders involved.

Agile Crew

Building on business value

  • AgileCrew Slider
  • AgileCrew Slider
  • AgileCrew Slider
  • AgileCrew Slider

We are The Agile Crew. Lets talk.

Agile Training

Corporate or Public

Equalminds contributes to improvement of your software development practices to a number of professionals and organisations. We offer courses in the field of Scrum/Agile and eXtreme Programming. The courses are taught by highly experienced trainers who work every day with teams and projects working on Agile or related technologies.

We offer both Corporate trainings for Organizations looking to go Agile and also Public trainings which are open to individual registration. Equaliminds offers a breadth and depth of courses to help you meet your needs.


Agile Developer

Your team is the crucial in running Agile. We believe a development team can learn to become Agile by creating a learning experience. Equalminds created a training for developers to be able to run as an Agile team

You want a team:

  • - that is commited on their goals
  • - that take responsability in communicating transparantly
  • - that can focus on what’s really important
  • - that take engagement towards code quality


On a 2-day course we let your developers experience what these skills mean in the succes and failure of real live projects. We will simulate a real development project. In this project we will learn the team to change their way of working in order to succesfully build software the business wants.

Get in touch



This 2-day course lays a solid foundation for individuals or teams to begin effectively using Scrum immediately. The Scrum framework, mechanics, and roles are emphasized with a focus on practical application. Whether you are brand new to Scrum or been practicing Scrum “under the radar” for some time, this course will level-set your team’s understanding and help you achieve higher goals by focusing on the fundamentals of lean principles and agility. This course will provides information and tools that you can use to ensure that Scrum is understood and implemented effectively by your team. This course covers Scrum basics, including the framework, mechanics, and roles of Scrum. But it also teaches how to use Scrum to optimize value, productivity, and the total cost of ownership of software products. Students learn through instruction and team-based exercises, and are challenged to think on their feet so they can put their knowledge to immediate use.


This course is specifically targeted to Scrum Masters. The roles that typically gain the most benefit from this course are:
• Development managers of all levels
• Technical Leads and software engineers
• QA leads
• Project and Program Managers

The lessons covered in this course are applicable to anyone in a role that supports a team’s efficiency, effectiveness, and continual improvement.


Attendees will be able to benefit the most from this class if they:
• Understand the basics of project management and requirements decomposition
• Have a desire to assume a greater leadership role on projects


1. Reasons for doing Scrum
2. Scrum Mechanics
3. Key Roles
4. Lean Definition
5. Scaling Scrum
6. Project Preparation
7. User Stories and acceptance tests
8. Story Estimating
9. Release Planning
10. Sprint Planning
11. Defining DONE
12. Sprinting Mechanics
13. Artifacts and Metrics
14. The Role of QA
15. Sprint Review
16. Sprint Retrospective
17. Distributed Team considerations

Get in touch

Product Owner

An effective Product Owner is one of the best predictors of product success, therefore, it is critical to understand the breadth of the role’s responsibilities in delivering a successful product. In this course we will teach you the tools and techniques to make you a highly effective agile leader through hands on workshops and lectures.

At the end of the 2-day course you will have gained sufficient knowledge and practice to:

• To conduct a collaborative user story writing session with your team
• To clearly articulate the acceptance criteria for each user story
• To break apart user stories that are too large to be completed in an iteration
• To effectively prioritize the backlog of user stories based on lean principles
• To identify the personas of your system and their needs
• Use backlog grooming techniques that will continuously improve the predictability and
effectiveness of your team


The people that will benefit the most from this course are:

• Product Managers and Product Owners responsible for the delivery of products.
• Business Analysts who are responsible for describing product features and their acceptance criteria
• Technical project managers who are responsible for partitioning features and scheduling deliverables.
• IT Managers responsible for a line of business systems.
• Scrum Masters can also benefit from this course as their role often includes coaching Product Owners.


Attendees will be able to benefit the most from this class if they:

• Currently manage a product, or will be managing a product in the near future.
• Have a clear sense of the challenges and opportunities facing their product
• Desire to know more about how to leverage agility to deliver more value to their customers


Agile Leadership
Managing requirements
Project Chartering
Program Management
Pragmatic Personas
Story Mapping
Features and User Stories
Acceptance Tests
Definition of Done
Release Planning Workshop
Product Backlog Grooming
Distributed Teams

Get in touch

Upcoming Courses

22-23 June 2013 – Agile Developers Training – 699 € (VAT exclusive) @ our office in Antwerp

Day 1

09:00 – 12:00 Introduction to Agile and Scrum as software delivery process
  • - What is scrum? What is Agile?
  • - Why Agile as total software delivery process.
  • - Release fast, get the feedback you want
  • - Business Value leads development.
  • - The Product Backlog as project artifact.
  • - Definition of Done
  • - Dealing with scope changes.
  • - Roles and respocabilities as scrum team
Lunch break
13:00 – 14:30  Sprint 1
  • - Develop a simple program. Howto start?
  • - Sprint planning – Use of available documentation and requirements – Start the first development sprint – Demo end of sprint.
14:30 – 15:00 Retrospective 1
  • - What went good? What went not so good?
15:15 – 16:45 Sprint 2
  • - Use the lessons learned of previous sprint.
  • - Sprint planning – Stories and keep your PBL up2date – Start the second development sprint – Demo end of sprint.

16:45 – 17:30 Wrap-up dag 1

  • - Retrospective 2 and wrap-up of the first day
  • - Results of Day 1. Have we delivered all stories according the definition of Done?
  • - How did the team experienced their new role? What are typical pitfalls.?
  • - A focus on team collaboration, communication and business feedback.


Day 2

09:00 – 9:30 a new day, a new world

  • - The Company has spotted a new opportunity. A new product has to be made.
09:30 – 11:00 Sprint 3
  • - Scope change – How to deal with this in reality. New Product Backlog items and enhanced interaction with Business.
  • - Sprint planning – Stories and keep your PBL up2date – Start the third development sprint – Demo end of sprint.
11:00 – 11:15 retrospective sprint 3
  • - What went good? What went not so good?
11:30 – 12:30 Sprint 4 Deel 1 Capacity interupts and backup’s
  • - A team member needs to fix a problem on another project.
  • - Sprint planning – Stories and keep your PBL up2date – Start the third development sprint
13:30 – 14:30 Sprint 4 Deel 2
  • - Continuation of the third sprint after a ‘holiday break’ – Demo end of sprint.
14:30 – 14:45 retrospective Sprint 4
  • - What went good? What went not so good?
15:00 – 16:00 Lessons Learned en feedback
  • - What have we learned these 2 days? What has become the developer role in the team?
  • - How can developers contribute to the succes and failure of a software delivery proces?
  • - How was the interaction with business?
16:00 – 17:00 team impediments list and Actions
  • - What are the impediments the team encountered during these 2 days?
  • - How does this list reflects itself in:
  • * team commitment
  • * responcability and transparent communication
  • * Focus on what’s really important
  • * Quality Engagement

Get in touch


I found this course very interesting and I found the methodology much simpler and easier than other traditional methods.’
- Anonymous customer



Check out what we've been working on



Website OpenCMS


Digital Matchsheets


Agile Developers Training
Zendesk RBFA

Zendesk RBFA

Zendesk Customer Service Implementation
Uptime Group

Uptime Group

Infrastructure Project Management
AG Insurance

AG Insurance

Intranet/Extranet/Internet Business Analysis


Platform between libraries and bookstores


Lorem ipsum
Everyday Football

Everyday Football

Mobile Application


Agile Coaching - Team & Management
P&V Insurances

P&V Insurances

Lorem ipsum

Meet the Team

We promise they won't bite

Luc Segers

Luc Segers

Project Manager

Founder of Equalminds !

I’m an experienced Product Owner and already in software development for more than 20 years.   I did real Business/ICT projects but also customer/online marketing projects. I’m passionate about Agile project approaches and love to be of any help to bridge the gap between business and ICT

Stefaan Vermael

Stefaan Vermael

Project Manager

co-Founder of Equalminds !

I’m a passionate agile advocate converging business, marketing and consumer needs when collaborating with teams on challenging projects. I am a hands-on personality who always looks up the intersection of Business and Technology.
Recently a Data Scientist fan.

Sven Dens

Sven Dens

Infra Project Manager

Infrastructure Agile enthousiast !

Trying to work on infrastructure projects in an Agile fashion,  a lot of time I come across huge obstacles but it is always a challenge to solve this the agile way.

Our Agile Crew

Our Agile Crew

Crew members

Our Agile Crew

The number of people is unlimited, we can create an Agile Team for you by means of our extensive network.
No mather what type of project (web, mobile, ERP, CRM, Bigdata, Infrastructure, …..), we can always be of any help to you.

If you are interested in a job, give us a call

The Equalminds team exceeded our expectations and provided an amazine agile crew to deliver our webproject!

- Satisfied Customer

Interested in our services? Get in touch and see how we can help.
Contact Us


We are hiring !!

If you are interested in a permanent position within our company or if you are a freelancer who is interested in working with us, give us a call

What can we offer?
Equalminds offers you a challenging job in an informal but dynamic environment with many opportunities to develop yourself. Our employment conditions which we offer may be described as competitive and our potential for growth will offer numerous challenges for you in the future.
Our office is located in Kontich (Antwerp, Belgium)

Interested in applying?

If you are interested in securing the position of one of underneath positions at Equalminds, we look forward to receive a short letter of application and your curriculum vitae via email: info@equalminds.be.

For more information about the vacancy and the recruitment process, please contact Luc Segers or Stefaan Vermael.
You can also send us your resume and accompanied letter to info@equalminds.be and we will contact you.

Product Owners – Agile Business Analyst

The Role
Equalminds has ambitious growth plans and is highly depending on  different teams that work on  projects at the customers premises. Each team needs a product owner that represents the different business stakeholders to the team who can make well founded decisions regarding priority and functionality of their area.

As a Product Owner you work together with our customers business to come to a Product Backlog that you prioritize, based on business value as well as input from development regarding complexity and impact.  You are expected to convey your vision to the team and outline the work to be done in each sprint.

The Product Owner role is a demanding role given that you have to consider our customers business stakeholders interests as well as the team´s needs to get their questions answered to ensure they can keep going.

• Act as primary interface to business stakeholders to gain in depth understanding of business vision and feature needs.
• Define and articulate the product vision to stakeholders as well as the development team(s)
• Develop and maintain detailed user stories in a prioritized product backlog which accurately reflects customer and business priorities.
• Create artifacts like use case diagrams, high level page flows, functional flow diagrams to ensure teams have an understanding of the big picture
• Function as a primary product champion with the development team to continuously ensure development activities are optimally aligned with customer needs
• Take the lead in explanation, estimation and planning meetings
• Actively participate in daily Scrums, sprint reviews, and team retrospectives.
• Inspect the progress on the product delivery at the end of every sprint to accept the delivered software.

• Bachelor or Masters Degree or at least some years relevant work experience as Product Owner (or Project manager position).
• Results-oriented, customer oriented, flexible, collaborative, problem solving skills, “Do it” mentality
• Proficient in Dutch and English (writing and spoken), French is a plus
• Effective verbal and written communication skills to interact with individuals at all levels in the organization
• A ‘Getting Things Done’ mentality  and preferably also  Project Management experience (agile or any other)
• Sense of humor and excellent communication skills; you can persuade and motivate people

For this role you’re a capable negotiator. Experience in working in an agile/Scrum environment is preferred but not mandatory.   Furthermore you’re able to manage priority and scope for technical development efforts

Why work at Equalminds?

• Your contribution is visible and will significantly contribute to our results;
• You work in an Agile environment with small scrum teams that include testers, developers and analysts;
• There are plenty of possibilities to develop yourself;
• Our working environment supports initiative and values your ideas;
• You will work on all kind of technology like web, mobile, crm, erp, …., depending on the project;


Due to our growth we are looking for several Scrum Masters to work in Software teams at in-house or on location to help deliver revolutionary technology projects

Seeking ScrumMasters / Agile Project Managers to manage the delivery of multiple projects through their expertise in Scrum, Product Ownership and Agile methodology. This represents an excellent opportunity for a Scrum Master seeking a new challenge in a truly Agile company (we all breed agile). An excellent benefits package with an above average pension scheme is in addition to a flexible, negotiable salary.

1. Act as ScrumMaster for 1 or 2 scrum teams with a focus on guiding the teams towards improving the way they work.
2. Facilitate sprint planning, retrospectives and sprint demos
3. Assist the product owner with keeping the backlog groomed
4. Ensure cross-team coordination if necessary
5. Reach out to the larger company network for impediment removal
6. Maintain relevant metrics that help the team see how they are doing
7. Coach and mentor other scrum masters in our  team. Ensure that our ways of working are consistent across the teams.


Knowledge and Qualifications: (Not essential but good to have)

1. Knowledge of the software development life cycle
2. Certified Scrum Master / Certified Product Owner / Certified Scrum Practitioner / Professional Scrum Master I / Professional Scrum Master II
3. Knowledge and/or experience of other agile techniques (e.g. Kanban, DSDM, XP)
4. Many years experience working in an agile environment, preferably in a variety of situations
5. Proficient in Dutch and English (writing and spoken), French is a plus

Technical Skills (Not essential but good to have):

1. Understand basic fundamentals of iterative development
2. Understand other processes and methodologies and can speak intelligently about them and leverage other techniques to provide value to a team/enterprise
3. Understand basic fundamentals of software development processes and procedures
4. Understand the value of commitments to delivery made by a development team
5. Understand incremental delivery and the value of metrics
6. Understand backlog tracking, burndown metrics, velocity, and task definition
7. Familiarity with common Agile practices, service-oriented environments, and better development practices



Our latest posts

When are Agile Requirements ready for development

As a product owner on an agile development team, I am responsible for populating the product backlog with a list of user stories to communicate the product direction.  A traditional lengthy requirements document is broken down into small parts that are formatted into a simple story told by the end user in hopes that anyone should be able to comprehend.  For example, “As a product owner, I need to add an attachment to a user story so that mock-ups are available for team members to reference.”

By design, a user story will force collaboration among the team members and ultimately increase the chances of a successful sprint iteration (not to mention invoking feelings of a shared product vision.)  If ample time is allotted for effective collaboration, user stories should be reviewed with part of OR the whole team PRIOR to sprint planning.  The goal is for development (and the rest of the team) to ultimately determine when a user story has all requirements ready for accurate tasking and estimation to occur.

All of my user stories have a lifecycle and the status includes ‘In Planning’, ‘Requirements Ready for Development’, ‘In Development’, ‘Ready for UAT’ and ‘Ready For Release’.  In this posting, I am focused on ‘Requirements Ready for Development’ which means the user story should have all of the information you and the team thinks they need in order to provide accurate estimates.

Below is a proven requirements checklist that should keep teams happy and less frustrated with incomplete requirements. Very important to note that each user story may NOT require all items in the checklist. In fact, including too much detailed requirements documentation is dangerous and can defeat the purpose of choosing an emergent iterative design process.

Possible Requirements checklist:

- User Story format is complete (role, desired feature and business case) *at minimum required
- Conditions of Satisfaction *at minimum required (COS)
- Communicate the Database Structure
- UI/UX Design (initially wireframes or mockups)
- Business rules including role based access control lists
- Workflows and triggers
- Acceptance Criteria (continuously refined during the sprint)

The Product Owner and stakeholders should be able to complete the user story format and conditions of satisfaction.  Conditions of Satisfaction (COS) may be a bullet list of items the user should be able to do if the story is implemented.  You can also think of COS as the ‘definition of done’ which allows the team to understand the work required to finish the story.

The rest of the checklist items should be reviewed with the team so much time is not spent on documentation that will not be read or even looked at by the team.

Communicating the database structure can be as simple as  including exactly what the input type looks like in the design or wireframe.  If needed, include a markup comment next to the field to include max char length or lookup table values to select from.
Workflows and triggers can also be included in the design or wireframe but if the instruction is complex enough, trace out the paths using data flow diagrams for precision.

Business rules are especially important to document in a single on-going list and attach updated versions of the list to the user story.  If different lists are maintained, it is easy to miss when one business rule modify’s or contradicts another.
In conclusion, it is the responsibility of the whole team to decide when requirements are ready for development.  The extent of which you choose to document requirements may depend on the structure of your whole team.  Most teams have at least a creative designer to deliver the look and feel requirements.  If the team is moving faster than the creative resource can deliver, then the product owner and the team must collaborate and compromise often enough to come up with a good way to perform acceptance tests on the features via a user interface.

Agile Product Ownership in a Nutshell

This is basically a 1 day product ownership course compressed into 15 minute animated presentation. There’s obviously more to product ownership than this, so see this is a high level summary (from our friends @ crisp.se)

What is Kanban

What is Kanban? This video will help you learn the essentials of Kanban and how it relates to the Scrum software development methodology in less than 5 minutes!

Find out why speed wins over perfection in business

Your company, product, service or application will never be finished. It will never be what you would consider to be “perfect.” Unfortunately, many entrepreneurs don’t get this concept. They lock themselves away in dark rooms and keep tweaking and tinkering, thinking that if they can just get everything perfect, their business will be a success.

In the meantime, those companies that simply launch their offering gain a major advantage. While they wouldn’t launch something half-finished  they realize that 90 percent perfect is “good enough.” They understand that there’s really no way to know every flaw, bug or feature request until they actually get their product in the hands of their intended customer.

That’s a philosophy we have at Equalminds. We practice what is commonly referred to as “agile development” by our peers. Essentially, instead of building a completely finished product  we tackle small projects and release them as and when they are ready. This allows us to iterate our software as needed. In fact, there are many benefits to be obtained when you realize that it’s better to release, rather than finish:

1. Speed wins

When you release quickly, you have an advantage over your competitors that tinker and tweak. While they’re trying to achieve imaginary perfection, your company is achieving real sales, real market share. While you don’t want to be sloppy, you also can’t afford to take your time.

2. Perfection equals second place

Let’s say it took you 2 years to release the perfect product. A whole lot can change in that time. Customer demands may have shifted. A competitor may have launched a cheaper, faster alternative. By being agile, you can set smaller, short-term deadlines that reduce the chances that your market will shift gears on you.

3. Who’s perfection is it anyway?

There’s no real way to know if your product or service is perfect until you get it into the hands of your customers. You may find that some features are never actually used. You know, the ones that delayed your launch by 2 months while you perfected them. Also, product bugs are just like their real-world insect namesakes, in that you never really find them all. Even though Apple thought it was releasing the perfect iPhone 4, it didn’t take long for its customers to find the major problem with the device’s antenna.

4. It energizes your employees

Being agile provides a better energy kick than ten cans of energy drink. Not only does your team get the chance to work on different projects, they get the satisfaction of continually launching new features. You reduce the chances of burnout that comes from months of working on the same project with nothing to show for it.

5. It energizes your customers

When you embrace agile development—and deployment—you also energize your customers. Equalmind’s customers get excited about any new feature we add to our dashboard.
It gives your customers, and your market, something new to talk about. It keeps your company “top of mind” while that competitor that’s still in “stealth mode” languishes in perfect obscurity.

Product Owners are VIP

We’ve talked about before how important product owners are in the whole agile process. This is still true. This will always be true!

These product owners are Very Important People as the PO is the person responsible for determining what the team is going to build. This is an important construct in Scrum because it unifies the voice of the business for the team. They are also the ones that set the priorities for the team as well. When there are changes in requirements, the PO continuously makes the decisions and gives the latest information to the team about the changing priorities. Development teams are always asking the questions: “What do you want me to build? What is the business priority?” – The PO tells the team!

Product owners also gain consensus and commitment in that the PO is the main person that is  responsible for giving the team unambiguous direction and ensures they don’t have to worry about conflicting business priorities or other distractions. They are the first line of support to the team from the business, as well as a first line of support from the customer. The PO is in a position that accurately represents the real customer and needs to be readily available to participate in the project proactively and continuously. As a driving force behind any project they must be visible, vocal, and objective.

Finally, PO’s write the stories. I’ve found that in different companies and clients the PO can either write it or not. I am of the opinion that since the the PO is the owner of what goes in the backlog then they write the user stories, acceptance tests, and priorities them by business value.

Regardless of client, I always have conversations around the involvement of their product owners. They are a very valuable resource in making sure the business priorities are set as well as the direction the team needs to build what the business wants.

Product owners are VIP!

Contact us

We are eager to to talk with you

Send a Message

Send a Message

Your Name (required)

Your Email (required)


Your Message


Contact Info

We are located near Antwerp in Belgium, feel free to drop by or give us a call if you want to contact us.

p Veldkant 33A – 2550 Kontich (Antwerp) – Belgium
O Stefaan Vermael : +32 486 80 13 21 Luc Segers : +32 473 51 01 67
@ info@equalminds.be
Etic Engagement Engagement eTIC registered supplier