Scrumban and a small team to ensure high-quality project delivery

Going from the design phase to the delivery phase always brings excitement but undoubtedly doubt. Project Managers and Product Owners wonder: What functionalities should we start production with? How can we stay within budget? And finally, what methodology should we choose so as not to overdo it and deliver?

Soft start

We have engaged three specialists for the project - a backend developer, a frontend developer and a tester. When we started, we knew that:

we want to build an MVP in the form of an application for students and an additional module attached to the main product for teachers,
we have obvious expectations, a well-designed design and support from our stakeholders (CTO, CEO, Marketing Team, sales team, German teachers),
we are aiming for a production release in March 2024 (at that time, we had the end of December 2023),
during the ongoing work, we have to include tests with teachers and students to obtain valuable feedback,
we have to ensure the scalability of the product and remember the assumptions in the Discovery phase (i.e. who we are doing it for, why, what long-term product strategy, etc. - I presented the conclusions in this article: click)

We started the development by:

Setting up the infrastructure, building the architecture of the new student application,
Integrating this application with the existing platform for teachers,
working on the first endpoints of the login process (probably a classic of every startup - you start by logging in).

This soft start allowed for a smooth, gradual addition of the frontend programmer and QA. We had a week or two of spare backend work on the frontend at each project stage. Our QA specialist, on the other hand, divided his time between working on our MVP and the team working regularly on the educational platform for teachers. This is how it went for the following weeks of work.

Scrumban - was it worth going crazy like that?

In my career, I have implemented projects using many methodologies and frameworks, such as AgilePM, Scrum, Kanban, and staged/waterfall. Using them had its pros and cons. Due to the specifics of working for a client (including the lack of Scrum Master/Agile coach roles, the need to synchronise work and releases with a parallel development team) and a completely anticipated project (because there was a design, an available client) - I decided to try a delivery framework with an exciting name: Scrumban. How did it look for us?

Firstly, abandoning cyclical sprints in favour of flexible releases

Working in regular sprints was out of the question - among other things, due to the size of the team, we knew that it would simply be a management "overkill". For us, the moment of meeting with the client for a review and deciding on a release was a reasonably flexible statement based on "Okay - interactive, working things are starting to appear - we feel that we should collect feedback on this part". However, once we had a demo, it was really effective, interactive and valuable. Additionally, we had such meetings planned in our roadmap (although they were supposed to be shiftable), and we conducted the demo about four times in total.

Secondly, the backlog and roadmap as the main sources of information

As standard, as in most agile frameworks - we worked with a backlog and roadmap in Jira. At the beginning of development, we built the roadmap of both solutions (the application for students and the new module for teachers). We corrected it continuously, considering change requests or delays/accelerations. The backlog lived daily - supplemented with tasks, stories and bugs - which were released by the Product Owner to the Kanban board of functions at the right time.

Thirdly, limiting team meetings to daily and refinement meetings

Our team was small (but agile!), so we decided to limit the daily to 3 times a week. Due to the abandonment of cyclical sprints in favour of flexible releases, we also eliminated planning meetings - we focused on refinements with the client in written form (on the messenger) and the form of cyclical meetings (twice a week). Thanks to this, we kept the backlog and the roadmap up to date and prioritised, and production breaks did not happen to us.

Conclusions

To sum up, the delivery phase in this project was exceptionally dynamic and demanding, but our approach based on flexibility and adapting to the client's real needs brought the expected results. The most important thing is that we delivered the project in 4 months (we closed the development work in April) and managed to release both solutions in production in May (client's business issues). Focusing on a small, essential team: a Ui&UX designer, two programmers, one tester and a Product Owner minimised the costs for the client and helped us maintain agility. Giving up cyclical sprints in favour of flexible releases allowed us to better adjust the pace of work to the real needs of the project and the second parallel team. Thanks to this, we could respond more effectively to feedback and introduce changes smoothly and without downtime. Limiting meetings to a minimum allowed us to maintain high team productivity without unnecessary breaks in work. Soft start allowed savings in the project and conclusions from the discovery phase - to reduce the rework time by 50%.