First of all, we’re finishing a major refactoring project - the second version of a huge KPI management system we did originally around two years ago. In a little more than half a year, we did some serious changes to the code and, most importantly, we decided to transfer it from AngularJS to ReactJS, mostly because it worked brilliantly with internal projects and we wanted to see how it fares in production.

The important bit here is that none of us had any previous contact with huge React projects, only some side-tasks, and internals. Through this refactoring project we gained two things in general: a new, enhanced, specialized tech stack for web applications, and a better understanding of scrum Agile framework.

Today, as a prelude to the meaty, code-filled stuff, I’d like to talk a bit about all good and bad decisions regarding our workflow, team management, and scrum cycle.

Let’s start with decent workflow

We’re a team that embraces the agile methodology, so one of our favorite tools/frameworks offered by agile approach is scrum. In its core, scrum is rather easy to understand yet it’s not always as easy to implement as it seems. Saying “We’ll be using scrum ‘cos it’s productive and efficient” isn’t enough. Each team member has to understand exactly why it is efficient and has a positive impact on the productivity for it to be really productive.

At first, we collectively assumed that we all know what scrum is about, what parts it consists of and why. And it created some problems with the workflow. Most likely, the source of this issue could be having new people in the team, who had different understanding of scrum. We also assumed that all aspects of scum must be present because it worked just fine in past projects. We also didn’t take specificity of this project into account at first.

Project’s start was quite painful from team management point of view. We started with a model scrum. We had all the plannings and groomings you need for a good scrum cycle. At least in theory. We had formed our sweet Definition of Done. We had a retrospective after each sprint. Also, our CTO, Michał Gryczka, played the role of a product proxy.

I believe it was possible to finish the project that way. However, it would be very painful and would most likely yield worse results. I also like to believe that there’s always place for improvements.

Transformation of the scrum cycle

The first thing we did was to establish regular contact with the product owner. Don’t get me wrong - Michał is a very good project manager and business software specialist. He surely knows and understands his job. However, because of project complexity (predictive analysis formulas, portfolio analysis, financial forecast, various simulations etc.), we had to have direct contact with the product owner who is strictly a financial expert. He exactly knew what functionalities are the most important. Also, working in corporate finance himself, he deeply understood user stories and use cases. Thank’s to this shift, we began to better understand why certain features have to be displayed in certain ways, what data the product users want to have visualized, etc.

Ok, so we got rid of the product proxy position to get closer to the product owner. Next on the list was a natural enemy of any team - endless meetings.

This one was rather simple to fix. We began to do grooming with product owner ourselves (earlier it was done by product proxy) which made separate planning unnecessary - we knew our velocity, we knew all the requirements so it took 5 minutes to plan the next sprint. When everyone understands what each feature does and how it relates to other features it clear what feature has the priority. All in all, instead of two ~4 hour long meetings that leave you tired, unmotivated and slightly confused, we did three rather short and intensive grooming meeting directly with the product owner. Of course, if there were no topics to discuss, such meeting was canceled.

Don’t underestimate daily stand-ups!

Now a little side note that has some connection to the topic. I have some associates don’t see the value of daily stand-up meetings. I beg to disagree. It’s really worth your time. Like, REALLY worth your time.

Have a difficult issue to resolve and can’t find an appropriate solution? Signal it during stand-up. You can be almost certain, someone will suggest a solution. Probably something you haven’t thought about.

Nothing sets up daily priorities as good as daily stand-ups. And, above all else, daily stand-up meetings let you know what your teammates do and what they plan to do next, so you can plan your own work accordingly. This is especially important in case of hard, time-consuming projects when there’s no time to talk with your teammates in ‘free time’. Thus, stand-ups helped us keep on the track of the project as a whole.

In the context of this project it did just that: helped us keep each other informed and find solutions to problems in-hand. I really encourage all opposed devs to try it.

The payoff

Picking and adjusting an appropriate team management methodology according to the project nature (it was basically an R&D project for us) and requirements is a very important aspect. It can either lead your team in the endless pit of miscommunication and unfulfilled deadlines or help them get the most ‘pro’ out of ‘productive’.

In the next part of Web Applications Development series I’ll talk more on the subject of our approach towards React in web apps development. If you have any interesting story regarding team management problems and solutions be sure to share and comment.