Engagement model
Agile process gives you the best final product in the shortest time.
Small incremental releases help to identify any issues early in the process, making it easier to respond to change. Requirements emerge and evolve as the product is developed. In agile development, change is accepted, in fact it’s expected. With Agile product development methodology our Scrum development team can effectively use time and resources and quickly provide an amazing end result. We also love an ability for our team to always reflect on how to become more effective.
Agile methodology values align with our values and approach to work, such as transparency in communication and in the relationship with clients and partners, flexibility and results-oriented and creative thinking and a collaborative approach to a problem-solution situation.
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." — Agile Manifesto
The first step is to have all requirements clearly defined and stored in Product Backlog. The work is then organised in fortnightly periods called Sprints that each have a specification, design, development, testing, and delivery phase. Before a new sprint starts, the Product Owner clearly specifies the top priorities which are then organised in tasks and completed within the sprint.
After the sprint ends, the Scrum team showcase the work completed within the sprint and gets valuable feedback from the Product Owner that can be used for further shaping the product in the future sprints.
Finished, working product increment is the primary goal of every sprint. It’s usually a piece of working software that adds to previously created increments, where the sum of all increments form a product.
Discovery is a separate mini project with a goal to create a working plan for the product build. It starts with an intensive, one-day information gathering workshop with a client which is organised to help our team better grasp the core components of the business and gain knowledge. We get an in-depth look at client’s story, who they are trying to reach and the key goals. We discuss the business model, core components of the product, individual requirements, target market and strategic techniques.
Based on these initial discussions, we create user flow maps that lay out the complete paths a user takes when using a product, establish a design concept, write User Stories that capture a description of the product features from a user perspective and store them in the Product Backlog, required to start the development.
As a [role] I want to [task] so that [goal]
As a customer I want to be able to cancel my hotel reservation so that I don’t loose all the money if an incident occurs.
Every 2 weeks, the team estimates the complexity of each user story in the Product Backlog during Backlog Refinement meeting. During this meeting, the Product Owner and the Scrum team define User Story details: goal, process, expectations, description, acceptance criteria etc.
The whole Scrum development team focuses its collective effort per Product Backlog Item and estimates of how difficult a user story is. The estimates are then discussed until consensus is achieved. This particular method, called scrum Poker, helps Product Owner to evaluate ROI, effectively prioritize items in the Product Backlog, and predict which items will be ready on time.
Each sprint starts with a Sprint Planning where the Product Owner prioritizes by importance User Stories, previously defined and estimated on the Backlog Refinement meeting, in the Product Backlog. Based on their previous experience and estimated effort for each user story, the team agrees on the number of user stories that they can commit to completing in each sprint.
The Scrum process is executed in a series of iterations which are called Sprints. Each sprint is started by a planning meeting in order to determine a sprint backlog – a list of the tasks to be performed during the sprint, and a goal that should be attained by the end of the sprint.
Each day, an internal stand-up meeting is held to assess the progress. The meetings take no longer than 15 minutes, all members come prepared with the updates and every member is asked these questions:
If a problem is identified it is solved without disturbing the process.
Inspect and adapt THE PRODUCT.
This is the time for the Scrum team to demonstrate the work finished within the iteration, get immediate feedback from project stakeholders, e.g. the Product Owner and celebrate their accomplishments.
Inspect and adapt THE PROCESS.
The team has an opportunity to openly express their thoughts on the sprint cycle. What went well and what can be improved in the following sprint. The things learnt from the Sprint Retrospective meeting provide valuable information for growth and increased optimisation as issues are addressed and solutions are put in place.
As with each sprint we get a finished, working product increment, release to the staging server is done after every sprint. Staging version is private and authentication is required to access. That way Product Owner can continuously monitor the progress, test the product and even invite other stakeholders to try out the product while it is still in the development phase and gain the valuable feedback that can be used for further shaping the product in the future sprints.
After a specific number of sprints and per client approval, we launch the product live.
Post launch, we’re on hand for any immediate bug fixes, makin sure your product is working perfectly. After that, we can offer ongoing maintenance support services per monthly retainer engagement model to keep the product in the top condition.
Our Scrum development team writes about agile methodology
