Agile development at Mtech – case Faba stock management

The semen stock management project for Faba was implemented using an agile development model. Both the customer and the implementer consider it an efficient work model.

How did everything work out in practice?

The stock management project team consisted of the Mtech development team, i.e. three full-time and one part-time software developers, a designer, a tester, and a project manager, together with a customer representative from Faba as the product owner. For the duration of the project, a meeting room was booked for the team as its dedicated shared working space to make communication inside the team and with the customer as direct and efficient as possible, just as the agile development model recommends.

Software development took place in fortnightly cycles, or sprints. Before each sprint, the team defined the content of the upcoming sprint based on which features were next at the top of the task list. All the necessary product features were listed in the task list in the order of priority. The product owner could change the task list during the product development cycle. At each sprint planning meeting, an appropriate number of features was selected from the task list in the order of priority.

The product owner was responsible for prioritising the features and the team then indicated how many features they were able to implement in the upcoming sprint. The product owner participated in all planning meetings and brought the customer’s insight and expertise into the project.  She acted as a link to this project inside the customer company, clarifying and communicating things between Faba and the development team.

During the sprint, the team had a short, 15-minute daily meeting each day. In the daily, they went through what had been done and what would be done that day. At the end of each sprint, the team held a demo session where the customer was presented with the current stage of product development. The day before, the development team held a pre-demo with the product owner to ensure that the product was in shape for the actual demo session. The demos made it possible to control the direction of development during the whole project.

The development team is happy with the model

The development team of the stock management project stated that they were very satisfied with the agile development model. The model was very flexible and could be tailored to fit the needs of the team. It took even less time to plan and define as procedures became more efficient. Because the team worked closely together in the same space, the members learnt to identify each other’s skills and strengths, making it easier to allocate tasks and use each member’s strengths efficiently.

The demos created good discussion between the team and the audience about what the product might need in the future. Answers to possible challenges and questions were also received already during the demo.

Project manager Mikko Lundholm from Mtech believes that the model has brought more transparency. The implementation of the various features could be easily monitored on a digital desktop, and the priority of the features to be done was visible to everyone. Planning was done on a whiteboard to give everyone the opportunity to participate in the planning and a thorough understanding of the use cases. During the project, the team became more autonomous as they could influence the content and implementation of the sprint. It was also easier for the project manager to manage the project because it was broken down into smaller pieces and feedback from the customer was received on an almost daily basis. Communication also increased inside the team and between the team and the customer’s product owner. A shared workspace located at the customer’s premises and the product owner’s close cooperation with the development team made communication uncomplicated.

Positive customer feedback

Product owner Anita Lampinen from Faba says that she found the agile development working methods inspiring. She was particularly pleased with learning something new and putting it into practice, as well as the experience of working together. She was also pleased with how the project progressed in the agile model: “Tasks came forth one at a time, not as one big lump. It was easier to manage the whole when the features were divided into small, value-creating parts. The focus remained better on the planned extent of the project, and it was easier to cut off the irrelevant tasks and move them to the next phase if necessary. We progressed efficiently and knew throughout the project where the implementation was going. There was an opportunity to discuss and explain issues directly with the developers, even very quickly. The developers came up with good questions and options that I had not thought about at all.”

Lampinen emphasises that to be successful, the agile model requires active participation on the part of the customer and working time must be set aside for this. Among other things, it would be good for the product owner to be involved in all possible meetings, including the dailies. “The working time required certainly depends in part on how well you know the topic, i.e. whether you have to do a lot of background work and sort things out with different customer employees,” she says.