Danijel Premužić: How PI planning impacts software development

If you ask his neighbours, Danijel Premužić is a family guy with a kid that loves football and a big lawn to mow. If you ask his colleagues, he is one of the early employees who worked a lot on our organisational development and is now on the tech management team.

Our recent conversation focused on his role as the Release Train Engineer, and the Agile Release Train (ART) concept he championed at the company. Agile Release Train is a part of the SAFe framework we’ve used in our company for several years now. It helped us improve our processes, which are important in planning and delivering high-quality software increments on time. 

A crucial part of ART is Program Increment (PI) planning, which helps us focus on developing what’s most important for the business.

Agile Release Train is a group of agile teams working together over a longer time, usually on delivering software incrementally. How many teams are working like this right now?

- Seven teams. Each has between 4 and 30 members. We are talking front-end and back-end developers, scrum masters, automation engineers, BI experts, and system architects. 

What exactly do you do as a Release Train Engineer?

- My job is to organize and prepare everything for Program Increment planning (which is an event) and to oversee development over the entire PI cycle. I coordinate with teams on all deliveries, both regular releases and hotfixes. I check in with Scrum Masters to see how things are progressing each week. I also help the System team decide on priorities - what they need to work on, what's most important.

How did you implement the Agile Release Train (ART)?

- We tried to introduce similar concepts before, but the company wasn’t ready. Although we were already using many elements of agile frameworks, Agile Release Train and PI planning were a serious level up. The first step was to introduce the Swiss management team to it and explain the benefits. Once we got them on board, we laid the foundations to roll out ART and hold our first PI planning. Now, dev teams from Varaždin and Switzerland work together on planning, creating specs, and deciding which increments (functionalities) to develop. 

I heard that term at your company so many times: what exactly is PI planning?

- It is a two-day event with over 20 meetings between Business Owners (BOs) and dev teams. BOs are people who represent the business. They work with end users of our solutions: for example salespeople in car dealerships or mechanics in service centers across the Emil Frey Group. In PI planning, we set priorities and outline the development plan for the next two months. It is a good practice to hold it in person. We host it in our Varaždin offices, with around 70 people participating. Some 20 of them usually arrive from Switzerland. Most of our business owners attend in person. We hold a PI planning every two months. We try to schedule at least three dates in advance.

What actually happens at a PI planning, with 70 people in the room?

- We use a technique called Weighted Shortest Job First (WSJF) to compare functionalities and rank them by importance. Then we look at the teams’ capacity. Then we decide which features we’ll work on. It’s important to find a balance between the business wants/needs and what the development team can deliver in the next PI cycle. While PI planning is a kind of a central event that draws a lot of attention, it is important to know that agile collaboration goes on at the company all the time. Our Product Owners, Business Owners and Business Analysts constantly work on documentation and features for the next cycle. At the same time, developers work on estimates and talk with System Architects about ways to develop and implement new functionalities. So ART is something that goes on daily.  

How do the teams take part in PI planning?

- Teams get a say in the process - they can vote to either approve or reject planned activities. If a team has concerns about an activity, like potential risks or unclear details, they can give it a lower rating. When that happens, they need to explain their reasons, and then we go back to re-planning. In those cases, only the team that flagged the issue takes part in the re-planning, which usually takes a few more days remotely.

You said you were looking to make your ART setup more flexible. What is that about?

- Yes, for a while now we’ve been working to make things more flexible in ART. This way, any team can work on any project, no matter the specifics. For example, if we need to develop ‘sales’ features, the whole organization can focus on that if it brings the most value to the business. To get there, we started rotating developers and specialists more often. After working in one team for about six months to a year, they move to another team. They learn about different parts of the system we’re building. It also makes the organization more flexible, allowing us to work on projects based on importance instead of just available resources.

What would you say are key benefits of PI planning and the whole ART concept?

- It helps us focus our development on what brings the most value to the business at the time. It also adds transparency. Business owners know exactly what’s being developed and for whom. And because so many people are involved in the process, it is easier for everyone to stay on the same page.

Your teams were familiar with Scrum, and they already used the SAFe framework. Did that help with the implementation of ART?

- Absolutely. I would say they adapted quickly. For developers, ART and PI planning means more visibility. They know what other teams are working on and they are in contact with the business in a very direct way. The business context we get in PI planning is of tremendous value. Business representatives share real data with us, like sales results. That makes a difference. We have talented and creative people on the team, and I saw how their ideas inspire business representatives to think in new ways.

Were there any challenges?

- There was an amount of questioning, and now and then you will hear opinions that this isn’t the ideal way to plan and ship increments. But I think it is better than what we had before. When the business team comes in and tells us about their challenges, we all get a much better understanding of what’s going on in the field. This is valuable for everyone, and I believe our dev organisation has become better.

Is PI planning only for development teams, or does it include the whole organization?

- According to the SAFe framework, PI planning is a session that includes dev teams, product owners, product management teams, and business owners. Right now we have one Agile Release Train, but we are preparing the implementation of an additional ART and value stream.

Overall, in what ways would you say the dev organisation has changed in the last six years?

- I would say things are much more structured now. We put a lot of effort into preparation, documentation, refinements, and planning. Six or seven years ago, we used to figure out a lot of the stuff as we went along. These days, we have things defined and planned in advance. It makes our jobs easier. And keeps us focused on delivering quality.

Looking back, how have you changed over these seven years? What’s different now?

- My first job was in a startup, which is a unique experience. For sure my mindset has evolved over the last six years. I’ve learned to value different opinions. When I first started here, I was the 23rd employee, and now we are a company of 150 people. There’s been a lot of learning and adapting along the way. In the beginning, I was juggling several roles at once (PO, SM, and QA), and now I’m focused on one part of the job. I handle stress much better. I used to work non-stop, thinking I had to solve everything on my own. Now I understand that I don’t have to do it all by myself because there are great people I can rely on.

What advice would you give to your younger self?

- To focus more on the people around me, to spend more time educating and motivating them. If you spot something you think is a mistake, offer your advice in a good, constructive way. Learning to take responsibility is a skill in itself. It is worth getting to the bottom of what taking responsibility really means, and getting to the point where you can actually do it.