In order to provide the most efficient approach on projects, BDT is applying a hybrid methodology based on the mixture of two main sub-methods of agile development.


Scrum is an iterative and incremental agile software development framework for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project.

A key principle of scrum is its recognition that during production processes, the customers can change their minds about what they want and need (often called requirements volatility), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly, to respond to emerging requirements and to adapt to evolving technologies and changes in market conditions. There are three core roles in the framework:


Product owner

The product owner represents the stakeholders and is the voice of the customer, who is accountable for ensuring that the team delivers value to the business. The product owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Scrum teams should have one product owner, this role should not be combined with that of the scrum master. The product owner should be on the business side of the project, and should never interfere or interact with team members on the technical aspects of the development task. This role is equivalent to the customer representative role in some other agile frameworks.

Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders is vital to steer the project in the right direction. Product owners bridge the communication gap between the team and its stakeholders. They serve as a proxy stakeholder to the development team and as a project team representative to the overall stakeholder community.

As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner to the stakeholders:

  • demonstrates the solution to key stakeholders who were not present at a sprint review;
  • defines and announces releases;
  • communicates team status;
  • organizes milestone reviews;
  • educates stakeholders in the development process;
  • negotiates priorities, scope, funding, and schedule;
  • ensures that the product backlog is visible, transparent, and clear.

Empathy is a key attribute for a product owner to have—the ability to put one’s self in another’s shoes. A product owner converses with different stakeholders in the project, who have a variety of backgrounds, job roles, and objectives. A product owner must be able to see from these different points of view. To be effective, it is wise for a product owner to know the level of detail the audience needs. The development team needs thorough feedback and specifications so they can build a product up to expectation, while an executive sponsor may just need summaries of progress. Providing more information than necessary may lose stakeholder interest and waste time. There is also significant evidence that face-to-face communication around a shared sketching environment is the most effective way to communicate information instead of documentation.[citation needed] A direct means of communication is the most preferred by seasoned agile product owners.

A product owner’s ability to communicate effectively is also enhanced by being skilled in techniques that identify stakeholder needs, negotiate priorities between stakeholder interests, and collaborate with developers to ensure effective implementation of requirements.


Development team

The development team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each sprint (the sprint goal). A team is made up of 3–9 individuals who do the actual work (analyse, design, develop, test, technical communication, document, etc.). Development teams are cross-functional, with all of the skills as a team necessary to create a product increment. The development team in scrum is self-organizing, even though there may be some level of interface with project management offices (PMOs).


Scrum master

Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The scrum master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences. The scrum master ensures that the scrum process is used as intended. The scrum master helps ensure the team follows the agreed scrum processes, often facilitates key sessions, and encourages the team to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.

The core responsibilities of a scrum master include (but are not limited to):

  • Helping the product owner maintain the product backlog in a way that ensures the needed work is well understood so the team can continually make forward progress
  • Helping the team to determine the definition of done for the product, with input from key stakeholders
  • Coaching the team, within the scrum principles, in order to deliver high-quality features for its product
  • Promoting self-organization within the team
  • Helping the scrum team to avoid or remove impediments to its progress, whether internal or external to the team
  • Facilitating team events to ensure regular progress
  • Educating key stakeholders in the product on scrum principles
  • One of the ways the scrum master role differs from a project manager is that the latter may have people management responsibilities and the scrum master does not. Scrum does not formally recognise the role of project manager, as traditional command and control tendencies would cause difficulties



A sprint (or iteration) is the basic unit of development in scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.

Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated commitment for the sprint goal. Each sprint ends with a sprint review and sprint retrospective, that reviews progress to show to stakeholders and identify lessons and improvements for the next sprints.

Scrum emphasizes working product at the end of the sprint that is really done. In the case of software, this likely includes that the software has been integrated, fully tested, end-user documented, and is potentially shippable.



At the beginning of a sprint, the team holds a sprint planning event that:

  • Communicates the scope of work likely during that sprint
  • Selects product backlog items that likely can be done
  • Prepares the sprint backlog that details the work needed to finish the selected product backlog items, with the entire team
  • Sets a four-hour time planning event limit for a two-week sprint (pro rata for other sprint durations) 
  • During the first half, the whole team (development team, scrum master, and product owner) agree what product backlog items to consider for that sprint
  • During the second half, the development team decomposes the work (tasks) required to deliver those backlog items, resulting in the sprint backlog
  • Once the development team prepares the sprint backlog, they commit (usually by voting) to deliver tasks within the sprint.


Daily scrum

Each day during a sprint, the team holds a daily scrum (or stand-up) with specific guidelines:

  • All members of the development team come prepared. The daily scrum...
    • ...starts precisely on time even if some development team members are missing
    • ...should happen at the same time and place every day
    • limited (timeboxed) to fifteen minutes
  • Anyone is welcome, though normally only scrum team roles contribute.
  • During the daily scrum, each team-member answers three questions:
    • What did I do yesterday that helped the development team meet the sprint goal?
    • What will I do today to help the development team meet the sprint goal?
    • Do I see any impediment that prevents me or the development team from meeting the sprint goal?

Any impediment (stumbling block, risk or issue) identified in the daily scrum should be captured by the scrum master and displayed on the team's scrum board, with an agreed person designated to working toward a resolution (outside of the daily scrum). No detailed discussions should happen during the daily scrum.



Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. This approach presents all participants with a full view of the process from task definition to delivery to a customer. Team members pull work from a queue.

Kanban in the context of software development can mean a visual process-management system that tells what to produce, when to produce it, and how much to produce - inspired by the Toyota Production System and by Lean manufacturing


The Kanban Method

Formulated by David Anderson, the Kanban Method is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. Visualisation is an important aspect of Kanban as it allows to understand the work and the workflow.

Four basic principles:

Start with existing process

The Kanban method does not prescribe a specific set of roles or process steps. The Kanban method starts with existing roles and processes and stimulates continuous, incremental and evolutionary changes to the system. The Kanban method is a change management method.

Agree to pursue incremental, evolutionary change

The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but have a higher failure rate due to resistance and fear in the organization. The Kanban method encourages continuous small incremental and evolutionary changes to your current system.

Respect the current process, roles, responsibilities and titles

It is likely that the organization currently has some elements that work acceptably and are worth preserving. The Kanban method seeks to drive out fear in order to facilitate future change. It attempts to eliminate initial fears by agreeing to respect current roles, responsibilities and job titles with the goal of gaining broader support.

Leadership at all levels

Acts of leadership at all levels in the organization, from individual contributors to senior management, are encouraged.


Open Kanban

Open Kanban Agile and Lean heritage is reflected in its core values: Respect for people, Courage, Focus on Value, Communication-Collaboration, and a Holistic or Systemic Approach to Change. Those values manifest in four key practices:

1. Visualize the workflow.

You cannot improve what you cannot see. Knowledge work needs a way to show progress. Kanban boards are one of the ways to display progress.

2. Lead using a team approach.

Without a team and leadership, nothing of significant value can be created or improved.

3. Reduce the Batch Size of your Efforts or Reduce BASE.

Science and the work from Donald G. Reinertsen has shown that when the batch unit of work is decreased, more can be accomplished. This principle goes beyond simply Limiting Work in Progress.

4. Learn and improve continuously.

This practice implies reflecting so that one can learn from experience, and it aligns with performing retrospectives and embracing Kaizen. In addition Open Kanban itself is open source and it welcomes contributions or extensions to the method.

Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. This approach presents all participants with a full view of the process from task definition to delivery to a customer. Team members pull work from a queue.

Kanban in the context of software development can mean a visual process-management system that tells what to produce, when to produce it, and how much to produce - inspired by the Toyota Production System and by Lean manufacturing.


Sources: -



Sentiments are the result of a never-ending clash between the irrational and rational components of our personality. 

Many variables concur to the end result of this clash: the topic and how relevant it is for us, our knowledge and competence on the subject, our current general mood and also the influence of the external environment (social media above all!).

Our sentiments are therefore the result of a very complex process, as it is assessing them...with a software! However, the so-called Artificial Intelligence (AI) does provide us with some understanding of them.

While ours is a very sophisticated and advanced Big Data technology, it’s up to us to make a good use of its output. This application of our Big Data technology, which is only one of those possible, converts sentiments into numbers with a many-digits precision! However, don’t let you be confused by this mathematical precision. Don’t jump to conclusions. Use your rational component to understand those numbers and integrate them with your experience and good judgment. This is the only way our powerful tool can help you gain a better understanding of...what’s going on!

We hope our tool will help you better understand the evolution of this very important campaign and, above all, the complexity of the voters’ behavior. 

We would also appreciate your feedback on our tool.

Thanks for your  attention and...enjoy playing with our “Sentiment Analysis” 

Roberto Fantino

Founder and CEO - Big Data Technologies srl