Did your project management approaches face failure and you experienced the lack of intended results? Despite implementing a verified system of action, your work doesn’t seem to be making progress? Well… it is well known to us from our own experience. In such cases we always look for other practices, the most optimal solution. At House of Angular we react to changes and always aim to adjust our plan of action to client’s requirements. Here you can read how the cooperation with us looks like.
Wondering which approach is best to choose to maximize the effectiveness of your project? Contact us here or message us for a chat. And if you want to find out what challenges we faced in one of our long-term angular projects and how we mastered them – keep on reading! 🙂
A few words about the project
Our main project goal was to create new modules. It is worth noting that during our work thousands of users were already using the application, so we were faced with the task of not only developing the existing functions and introducing new ones, but also maintaining the so-called “live” application. This was associated with the need to respond to current changes and solving current user problems, while at the same time maintaining a constant work rhythm on new modules.
Our beginnings of working in SCRUM
From the beginning we knew that the new angular project would be demanding and that we would need a methodology which would allow us to adapt well to the dynamic work environment and frequent changes in requirements. So we decided on using SCRUM.
As it is known, SCRUM owes its popularity to the fact that it responds best to a complex and dynamically changing work environment. Working in short periods of time – sprints give a number of advantages, including above all, greater flexibility.
Unfortunately, in this case, the SCRUM approach didn’t meet our needs, and working in iterations of several weeks didn’t get us close enough to our goals. Why? We hasten to explain.
Why didn’t sprints work in our case?
Initially, we divided the project into 2-week long sprints, taking into account the priorities set by the client. Unfortunately, despite the pre-established rules of operation and regular planning meetings, the set priorities frequently changed during the sprint. As a result, sprints weren’t regularly completed, causing everyone involved a lot of frustration – the developers, our PM, and the client.
First attempts at solving the problem
We started by changing the iteration length, hoping that shorter sprints would give the client enough flexibility and introduce some constancy of requirements to our development. Shorter sprints were supposed to make the work progress per sprint satisfactory, which would also influence the motivation and effectiveness of our subsequent activities. However, this approach did not solve the problem. So, another change was necessary.
Seeing that SCRUM didn’t completely meet our expectations, we decided to look at other agile approaches which would allow our client to modify priorities more freely, which keep changing due to the needs of the end-users of the system.
While preparing to change the angular project workflow, we also analyzed other problem sources. One of them turned out to be imprecisely described requirements. Unfortunately, due to the resource constraints on the customer’s side, many of the sprint tasks did not contain a precise specification and acceptance criteria, and all the tools that we tried to introduce – e.g. ready-made templates designed to make describing requirements easier – did not bring the expected results.
Our solution? We change SCRUM to SCRUMBAN
We started to think – what else can be done? What should be changed? And then, the search for solutions led us to what could be the answer to our needs … SCRUMBAN! So what changes exactly did we implement thanks to the use of scrumban?
Giving up on two-week sprints
We replaced them with a work rhythm dependent on cycles. These cycles were based on the time when specific versions of the application were released. This allowed us to adapt better to sudden changes, which no longer disturbed our operations as much as in the case of sprints.
Changing communication with the client
Our weekly meetings were now held with the entire team on the client-side, not just with one person like before. This reduced misunderstandings that resulted from relying on the knowledge of only one person and facilitated communication between team members. We also implemented regularly scheduled status meetings with the client to understand emerging changes better and to improve the planning of our work in terms of priorities.
Changing the workflow
To solve the problem of imprecisely described requirements, we changed our workflow. We introduced new statuses to the tasks, such as “planned” status, which contains tasks that were previously analyzed by developers. Only such tasks, analyzed and understood by the team, were assigned to a particular developer. We also decided that the ‘in progress’ column should not contain more than one task per developer. If the planned tasks have changed, they remain in the column of tasks already described and waiting for clarification.
Additionally, we introduced retro meetings, which take place when versions are switched. This gives us a full picture of the progress we made between releases.
In conclusion, sometimes the effectiveness of our approach towards project implementation is worth analyzing and changing if we see that approaches and methods used so far don’t bring the desired results 🙂
If you’re also wondering how to maximize the effectiveness of your project, contact us here or use our chat.