Agile Workflow (Continuous Lean Life Cycle)— StartUp to ScaleUP
Project Management helps maintain a disciplined approach at the work. It’s not only more productive but it is more fun and a feeling of accomplishment across entire startup.
We implemented fully automated calculation system for quality assurance to define the severity based on customer related values.
We will highlight that today.
StartUp to ScaleUp Journey:
As it requires to change strategy and practices very rapidly to constantly adapt to the evolving context.
The best way to deliver more value to our users faster. We choose to drop iterations and start releasing continuously by embracing the continuous lean lifecycle that disciplined agile showcases.
Instead of having iterations that push back the release of bug fixes and feature improvements, the Kanban based approach enables a continuous stream of development. Which is particularly useful to react swiftly to constant flow of requests. To achieve this, we have pools of work that you see below.
Four different pools (Business Value, Expedite, Fixed Delivery Date, Intangible Options) that are constantly prioritised and from which work is pulled only when capacity is available until the word is released directly into production.
We start with the pool, we pull it when we have the capacity, we work on it and release it directly into production, in a continuous stream of development. This enables teams to avoid task-switching, to avoid this partially done work and to avoid extra processes which are the main factors of waste in a company.
One of the main factors of waste, impacting software products is Bugs.
One of the main factors of waste, impacting software products is bugs. So the question we have to answer as we start scaling up is:
How to handle bug reports at scale?
When we received thousands of bug reports, it quickly becomes overwhelming and it’s very difficult to know what to start with. Our goal is to make it easy to always know what to work on next through a reliable and intelligent prioritisation system. We want to always know who is responsible for what by assigning very precisely per rule and we want to always know what’s the status per team so that we are continuously aware of potential roadblocks and find where they come from.
At my startup we collect reports from multiple sources either through user tickets, bug forms, internal reports and canny feedback. Which means we have to make the system work for each of them and revamp our current system to accommodate for more flexibility as we continuously improve over time.
Once this base is prepared we get into the most important part, the Bug evaluation.
To prioritise, we want to compare the severity of the bug to the effort required to fix it. So we implemented fully automated calculation system for quality assurance to define the severity based on customer related values (Impact, Reproducibility, Total MRR, Angriness).
We define bug severity based on customer related values while developers would define the effort based on their estimation and level of confidence. We needed a clear ownership of bug to streamline the flow.
While the developers would define the effort based on their estimation and level of confidence. We also wanted to make sure that we had clear ownership for each bug, so we split our assignees into dedicated team fields for both QA and Dev. So now that we have the severity and the effort our automated system provides a qualitative priority that enables to group bugs into four categories — Do Now, Do Next, Do Later and Don’t Do.
But the issue is that this qualitative approach alone is not very precise because for example, how we can define, what should be done now when you have hundreds of bugs in the Do Now category. It’s to solve this problem, we introduced a custom quantitative priority as a complement to the qualitative categories, so that we always have a precise calculated number associated to each bug and now it’s easier than ever to know that number 72 is more important than number 50 in the Do Now category which are both more important than the Do Next category that is below.
The final step is to make sure that once a bug enters the system it gets through flow that considers all the dependencies between teams and provides each of them their own prospective to accelerate value delivery and improve collaboration while providing more visibility for everyone.
