Agile methodology in the process of delivering the procurement system – how we work?

P2P process automation – a novelty or total obviousness?
30 January 2019
Agile in our work – what does the Client gain? part II.
17 July 2019

Introduction

Agile is a methodology that increasingly appears in the context of project management methods – especially in the IT industry. Why did it arise and where did it come from? First of all, it is a response to market requirements, which enforces flexibility. The specific roles in the team, the detailed tasks and the time to perform them make the process of implementing the purchasing system in cooperation with our clients more efficient and effective.

The rapidly changing world has meant that the current waterfall approach has stopped working. Why? It often led to the creation of a product that was already obsolete when it came to the market.

Agile, which increases the flexibility of work as a response to dynamic changes and requirements. What’s more, the Agile Manifesto created many ways to run and implement projects. The most important projects include, for example, the Scrum methodology. However, working in agile methodologies often has many common features.

It is worth emphasizing the most important principles of working in the Agile methodology, which resulted in success on the market as well as the weakness of this approach. Below we outline the assumptions of the Scrum methodology, because we use it in the implementation of NextBuy.

Where to start? Work in the Sprint cycle

When analyzing the Agile methodology, you first need to start with the division and organization of the work of the whole team. Sprint is a period of time intended for carefully planned development work. It usually takes from 2 to 4 weeks. During the Sprint and after its completion, the activities are reviewed, and then usually the next one starts immediately after the current sprint ends.

Comparing the distribution of tasks in Sprint for a short period of time with projects carried out in the waterfall methodology, Sprint significantly reduces the risk. The effects of increments are presented to the customer after the end of each Sprint, thanks to which regular feedback is received on a regular basis as well as a reaction to potential errors. The design risk is limited in many cases to one Sprint, where something developed incorrectly by misinterpreting the requirements. In the case of the waterfall method, misunderstanding the requirements is often only diagnosed after a few months of work.

Sprint planning and backlog refinement

Each Sprint needs proper planning. A methodology, such as Scrum, provides for a special meeting – Sprint Planning, which takes place at the beginning of each Sprint, in order to decide what to do. The developer team values the most-important requirements to be met in the nearest Sprint. Backlog refinement, which is regular browsing of the backlog (current tasks) is also important to make sure that there are only important tasks there, and also that they give them the right priorities. The Product Owner (PO) is responsible for this.

Defining requirements – what are Stories?

An interesting and one of the most recognizable elements of the Scrum methodology is the definition of requirements in the form of thales. Stories – commonly referred to as tales – is a brief description of the requirements that contain information about who needs the functionality and for what purpose. Stories should also contain Acceptance criteria, i.e. elements that are necessary for the requirements to be considered fulfilled.

Retrospectives – insight into activities

An important element of the SCRUM method is also a retrospective – Sprint Retrospective. Agile methods assume continuous improvement. A retrospective is a meeting, the purpose of which is to review the team activities carried out in a given Sprint. What’s more is the confirmation of what in Sprint worked and what is to improve. The conclusions drawn are implemented in the next Sprint.

Specific roles in Scrum

The Scrum theory defines specific roles in the team. Scrum Team creates:

  • Scrum Master, who is the guardian of compliance with the rules of Scrum as well as the leader who helps the team overcome all difficulties encountered by addressing them to the right people,
  • Product Owner who is responsible for the final look of the product and for prioritizing tasks
  • Development Team, which consists of professionals providing real growth.

What should SCRUM Team be like? Primarily: cross-functional, which means that the team is to consist of people with the necessary competences to perform the tasks and self-organizing – that is, the team knows exactly how to manage their work.

The work of our team

As a company that has extensive experience in implementing the purchasing system (see the case study tab) we have changed. Last year we changed the way we work – we switched to the Agile methodology and we are very happy with ourselves! Currently, we can present certificates that we received after passing the Scrum exams on the official website of the creators of the system: Ken Schwaber and Jeff Sutherland – our team stood up to the challenge and among the candidates there are: 8 Scrum Master certificates and 1 Product Owner.

It is not the end! We will continue to develop!

 

 

ZOBACZ DEMO